AGARD^-503 


AGARIH»»>503 

AGARD 

ADVISORY  GROUP  FOR  AEROSPACE  RESEARCH  &  DEVELOPMENT 

7RUEANCELLE  92200  NEUiLLY  SUR  SEINE  FRANCE 


AGARD  CONFERENCE  PROCEEDINGS  S03 

Software  for  Guidance  and  Control 

(Les  Logiciels  de  Guidage  et  de  Pilotage) 


I 


~  NORTH  ATLANTIC  TREATY  ORGANIZATION 

:  ’V'  'I  .':-MENT  A 

I  I  •  '"i  ;  •  lulacso; 

i  !■  >  ijiiastiited 


AD-A244  894 


Distribution  and  Availability  on  Back  Com 


AGARD-CP-503 


ADVISORY  GROUP  FOR  AEROSPACE  RESEARCH  &  DEVELOPMENT 

7RUEANCELLE  92200  NEUILLY  SUR  SEINE  FRANCE 


AGARD  CONFERENCE  PROCEEDINGS  503 


;  Ac(j*.»aio«  Ter 

i 

;  B^iO  Til) 


(" 
I  ! 


r;'. uriou! 

Software  for  Guidance  and  Control  i  *  ■  - < -  '  t  ^ 

'  CHri/oi' 

(Les  Logiciels  de Guidage et de Pilotage)  ,i)i,n  ,  Sf.soini 

if\A 


16656 


Papers  presented  at  the  Guidance  and  Control  Panel  52nd  Symposii.m 
held  at  the  Helexpo,  Thessaloniki,  Greece,  from  7th  May  to  10th  May  1991. 


North  Atlantic  Treaty  Organization 
Organisation  du  Traite  de  I'Atiantique  Nord 


•1  11  27  056 


The  Mission  of  AGARD 


According  to  its  Charter,  the  mission  of  AGARD  is  to  bring  together  the  leading  personalities  of  the  NATO  nations  in  the  fields 
of  science  and  technology  relating  to  aerospace  for  the  following  purposes: 

—  Recommending  effective  ways  for  the  member  nations  to  use  their  research  and  development  capabilities  for  the 
common  benefit  of  the  NATO  community; 

—  Providing  scientific  and  technical  advice  and  assistance  to  the  Military  Committee  in  the  field  of  aerospace  research  and 
development  (with  particular  regard  to  its  military  application); 

—  Continuously  stimulating  advances  in  the  aerospace  sciences  relevant  to  strengthening  the  common  defence  posture: 

—  Improving  the  co-operation  among  member  nations  in  aerospace  research  and  development; 

—  Exchange  of  scientific  and  technical  information; 

—  Providing  assistance  to  member  nations  for  the  purpose  of  increasing  their  scientific  and  technical  potential: 

--  Rendering  scientific  and  technical  assistance,  as  requested,  to  other  NATO  bodies  and  to  member  nations  in  connection 
with  research  and  development  problems  in  the  aerospace  field. 

’1  he  highest  authority  within  AGARD  is  the  National  Delegates  Boaid  consisting  of  officially  appointed  senior  lepresentatives 
from  each  member  nation.  The  mussion  of  AGARD  is  earned  out  through  the  Panels  which  arc  composed  of  experts  appointed 
by  the  National  Delegates,  the  Consultant  and  Exchange  Programme  and  the  Aerospace  Applications  .Studies  Programme,  The 
lesulls  of  AGARD  work  are  reported  to  the  member  nations  and  the  NATO  Authorities  through  the  AGARD  series  of 
publications  of  which  this  is  one. 

Participation  in  AGARD  activities  is  by  invitation  only  and  is  normally  limited  to  citizens  of  the  NATO  n.ilions. 


The  content  of  this  publication  has  been  reproduced 
directly  from  material  supplied  by  AGARD  or  the  aulhors, 


Published  September  1991 

Copynght  ©  AGARD  1991 
All  Rights  Reserved 

ISBN  92-d35-()f)29-4 


Printed  by  Specialised  Prinimg  Semces  Umited 
40  Chipvell  Lane,  Loughton,  Essex  IGIOJTZ 


II 


Theme 


Software  is  of  increasing  importance  in  guidance  and  control  systems  and  indeed  in  many  cases  is  the  pacing  item  in 
development.  Guidance  and  control  software,  while  embradng  a  wide  range  of  software,  has  emphases  which  include  high 
integrity  considerations,  hard  real-time  constraints,  the  implications  of  a  still  evolving  hardware  and  systems  architecture,  and 
the  need  to  meet  delivery  schedules  with  high  productivity  under  the  constraints  of  onerous  customer  requirements  for 
documentation  and  visibility,  and  in  the  light  of  strong  defence  and  air  worthiness  standards  and  requirements  Time  schedules 
are  frequently  short  since  much  guidance  and  control  software  is  required  early  in  the  flight  testing,  and  typically  software 
^^development  is  undertaken  tn  the  context  of  still  evolving  requirements  and  developing  programme  phases.  ^ 

The  software  climate  in  which  this  takes  place  is  one  in  which  tliere  is  a  general  trend  towards  high  level  languages,  integration  of 
support  tools,  intioduction  of  mathematical  formalisms  into  the  design  and  verification  processes,  control  of  software  sizing 
and  better  cost  estimating,  and  frequently  a  rapid  turnover  of  programmers,  s 


There  is  often  a  wide  gap  between  concept  and  practice,  and  organizations  will  succeed  which  can  bridge  the  gap  effectively, 
bringing  modern  methodologies,  well  supported  by  software  tools,  to  bear  on  the  problem  and  understanding  how  to  apply 
these  methodologies  and  use  the  tools.  ^ 

To  assist  this  understanding  thrsymposium  covered  general  requirements  on  the  software,  software  requirements  capture, 
design  methods  and  support  environments  for  real-time  software,  coding  techniques,  and  verification  validation  and 
certification,  ^ 
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l.es  logiciels  revetent  de  plus  en  plus  d’importance  dans  les  systemes  dc  guidage  et  de  pilotage.  Eii  effet,  le  logiciel  est  souvent 
I'element  critique  pour  le  developpement  des  systemes. 

Bleu  qu'il  existe  une  large  gamme  de  logiciels  de  guidage  el  de  pilotage,  I'accenl  est  mis  pnncipalement  sur  les  considerations 
suivantes:  la  haute  integrite,  les  contrainies  temps  reel  du  materiel,  les  consequences  de  revolution  permanente  des 
architectures  systemes  et  materiel,  le  respect  des  delais  de  hvraison  pour  des  volumes  de  production  eleves,  la  demande 
onereuse  de  documentation  de  la  part  du  client,  les  contrainies  d'intelligibilitc  du  logiciel,  et  la  rigueur  des  specifications  et 
normes  militaires  et  aeronautiques.  \.e$  delais  sont  souvent  courts,  puisque  bon  nombre  des  logiciels  de  guidage  el  de  pilotage 
sont  demandes  des  la  premiere  phase  des  essais  en  vol;  typiquement,  le  logiciel  est  cree  pendant  que  les  besoins  conlinuent  a 
evoluer  dans  le  contexte  des  differentes  pha.ses  evolutives  du  programme. 

L’environnement  logiciel  de  ce  processus  est  caracterise  par  les  langages  evolues,  I’integralion  des  outils  de  developpement, 
I’emploi  de  formalismes  malhematiques  dans  les  methodes  de  conception  el  de  verification,  le  controle  du  dimensionnement 
des  logiciels,  la  recherche  d'une  meilleure  esUmation  des  couts  el  le  renouvellemem  frequent  des  programmeurs. 

II  existe  souvent  un  grand  pas  a  franchir  pour  passer  du  concept  a  la  pratique.  Les  organisations  qui  reussiront  a  I’avenir  seroni 
celles  qui  saurom  franchir  ce  pas  de  fagon  efficace,  en  se  servant  de  methodologies  modernes,  bien  appuyees  par  des  oulils  de 
developpement,  et  qui  auront  compris  I'application  de  ces  methodologies  et  la  mi.se  en  oeuvre  de  ces  outils. 

Afin  de  faciliter  celie  comprehension,  le  symposium  a  examine  les  sujets  suivants:  conditions  generates  requises  pour  les 
logiciels,  elaboration  des  specifications,  methodes  de  conception  el  eiivironnenienls  dc  soutien  pour  les  logiciels  temps  reel, 
lechmques  de  codage,  et  verification,  validation  et  certification. 
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A  Survey  of  Available  Tools  and  Methods  for 
Software  Requirements  Capture  and  Design 

by 

D.J.Thewlis 
GEC  Marconi  Ltd.. 
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Slanmore,Middlesex, 

HA7  4LY, 

England. 


1.  Introduction 

In  this  paper  I  discuss  (he  contribution  to  software 
development  of  the  ttxtls  and  methods  currently 
available  to  a.ssi.st  with  the  early  part  of  the 
.software  development  life  cycle  -  that  is  tools  and 
methods  for  Requirements  Capture  and  de.sign.  For 
all  parts  of  the  life  cycle  the  requirement  for 
Quality,  that  is  Quality  Assurance  and  Quality 
Control  is  fundamental.  If  it  is  lacking  then,  at 
worjit,  the  software  will  never  achieve  a  deliverable 
state,  if  delivered  it  will  not  work  well  and  will 
probably  not  be  maintainable.  The  word  ’Quality’ 
is  u.sed  in  an  informal  sense,  this  paper  is  not  about 
Quality  Management  or  Quality  Control  .so  thc.se 
requirements  are  not  di.scussed  in  detail; 
neverthcle.ss,  the  case  is  made  that  the  tools  and 
methods  nsed  determine  the  achievable  quality  of 
the  delivered  .sy.stem.  There  is  a  sense  in  which  the 
output  from  these  tools  is  part  of  the  delivered 
system.  In  general,  the  quality  requiremenLs  for  a 
large  or  complex  sy.stem  are  greater  than  tho.se  for 
a  small  or  simple  system,  .so  the  tools  and  methods 
now  available  make  it  feasible  to  build  systems  of  a 
size  or  complexity  which  would  be  impossible 
without  them.  The  newer  ttwls  which  are  emerging 
should  enable  the  inevitable  demand  for  even 
bigger  systems  to  be  met. 

Although  the  methods  emerged  before  ttxils  were 
created  to  instantiate  them,  the  words  ’method’  and 
’tool’  are  effectively  interchangeable.  Taking  a 
simple  example  from  a  related  area;  critical  path 
analysis  of  a  network  is  a  project  planning  method. 
It  would  be  practically  impossible  to  apply  this 
method  to  even  quite  a  small  project  without  the 
use  of  a  network  analysis  programme  -  the  tool.  To 
the  protect  manager  his  project  management 
metnod  is  the  tool  which  he  uses.  It  is  .so  with 
software  design  methods  and  tools.  Methods  on 
their  own  are  of  little  use:  fortunately,  we  now 
have  tools. 

My  company  has  u.sed  the  MASCOT  method  and  is 
ex[)erienced  in  the  use  of  the  following  tools: 

Teamwork  (Yourdon) 

Software  through  Pictures  (Yourdon) 

Speedbuilder  (Jackson) 

PDF  (jack.son) 

We  are  experimenting  with  the  use  of  a 
Hierarchical  Object  Oriental  Design  (HOOD)  tool, 
so  in  this  paper  the  discussion  of  methods  and  their 


contribution  to  software  development  comes  from 
this  experience. 

2.  Requirements  and  Design. 

Current  Dogma  is  that  we  collect  together  a 
complete  specification  of  the  customers 
requirements  before  embarking  on  design.  Further, 
we  should  ensure  that  this  specification  is  not 
contaminated  by  design  or  implementation 
considerations.  The  arguments  for  this  are 
powerful.  One  such  is  that:  if  we  approach 
requirement  capture  with  preconceived  ideas  on 
implementation;  we  shall  try  to  make  the 
requirements  fit  the  design  rather  than  the  design  fit 
the  requirements.  At  worst  we  fail  to  capture 
important  parts  of  the  requirement,  at  be-st  we  have 
a  less  than  optimal  design.  Ward  and  Mellor  1 1 1, 
amongst  others,  have  developed  this  argument. 

They  argue  that  technology  is  now  so  developed 
that  technology  limits  are  now  irrelevant  and  we 
can,  .so  should,  deliver  exactly  what  the  customer 
requires. 

That  technology  limits  are  irrelevant  is  debatable 
and  is  covered  in  section  3.  Equally  debatable  is 
whether  it  is  possible  to  acquire  the  full 
requirement  prior  to  starting  the  design.  In  practice 
the  design  process  uncovers  so  many  questions 
about  the  requirement  that  it  becomes  impossible  to 
separate  the  proces.ses  of  requirement  capture  and 
(high  level)  de.sign.  The  Starts  Guide  121  to 
soltware  methods  and  tools  accepts  this,  treating 
both  requirements  and  design  in  the  same  chapter 
and  reporting  that  many  of  the  tools  they  cover 
apply  to  both  parts  of  the  life  cycle. 

Computers  have  existed  for  about  forty  years  and 
have  been  widely  used  for  twenty.  There  must  be 
few  situations  left  where  computers  are  being  used 
for  the  first  time.  Most  projects  are  to  prcxluce  a 
.system  which  is  in  .some  ways  better  than  an 
already  existing  sy.stem.  The  customers  perception 
of  his  r^uirements  is  coloured  by  his  knowledge  of 
current  implementations.  And  considerations  of  cost 
and  risk  reduction  constrain  the  supplier  to  use 
existing  ideas,  designs  and  code  wherever  possible. 
Thus  the  ideal,  establishing  a  requirement  free  from 
implementation  considerations,  is  rarely  achievable. 
Most  writers  on  methods  and  tools  assume  the 
ideal. 

There  are  few  projects  where  the  ,cquirements 
established  at  the  beginning  of  development  are  still 
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valid  at  the  time  of  delivery.  Requirements  change 
with  time,  so  the  methods  and  ttxils  have  to  be 
robust  enough  to  cope  with  changes  m  the 
requirement.  Fortunately,  the  tools  which  have 
emerged  in  the  last  few  years  do  seem  to  work  well 
in  the  real  world. 

Although  the  methods  discussed  have  features 
which  apply  particularly  to  the  initial  requirements 
capture,  such  features  are  not  discussed  in  this 
paper  as  they  are  not  lelevant  to  the  main  argument 
and,  in  the  author’s  opinion,  of  less  importance 
than  the  facilities  which  assist  design  and  the 
control  of  design. 


3.  The  Software  Problem. 

Computer  hardware  performance  increases  at  a 
formidable  rate  Some  years  ago  the  IBM  UK 
Research  Director  stated  that  prrKessors  were 
getting  "better"  at  a  rate  of  45%  compound  per 
year.  Memory  and  data  .storage  were  not  doing  so 
well;  for  them  the  rate  was  25%  compound  per 
year  "Better"  means  almost  any  ratio  which  is 
likely  to  interest  system  develo^rs.  that  is  MlPs  or 
bytes  as  the  numerator  and  such  things  as  price, 
si/e  or  power  consumption  as  the  denominator. 
The.se  rates  have  applied  since  the  early  days  of 
computing  and  are  likely  to  apply  for  the 
fore.seeable  future 

It  has  long  been  the  hope  of  software  developers 
that  some  of  this  ’surjilus’  power  could  be  used  to 
aid  the  task  of  software  engineering.  The  statemcitt 
that  the  industry  has  developed  to  an  extent  that  we 
are  problem  limited  rather  than  technology  limited 
m  reference  1 1 1  is  one  in  a  .sequence  of  similar 
statements  going  back  to  the  early  days  oi 
computing  In  practice,  die  technology  limits 
continue  to  apply;  the  demands  lor  speed  and 
functionality  which  systems  engineers  are  placing 
on  computer  system  designers  are  increasing  as 
quickly  as  the  hardware  technology  improves 

It  therefore  .seems  likely  that  the  size  of  system  that 
developers  are  invited  to  construct  will  increa.se  at  a 
rate  similar  to  that  at  which  hardware  improves. 
Hxperience  within  our  organisation  supports  this 
tixamination  of  similar  projects,  one  started  four 
ears  later  than  the  other,  showed  that  each  project 
ad  a  similar  size  team  working  for  about  the  same 
time,  but  the  later  project  produced  I'k  times  more 
.software  than  the  earlier  project  The  methods  and 
Ux)ls  used  by  developers  have  to  keep  pace  with  the 
increasing  size  of  software  projects. 


4.  Quality. 

A  tew  men  with  buckets  and  shovels  can  mix 
concrete  and  lay  a  garden  path  or  the  foundations 
for  a  garage  Perhaps  a  large  number  of  men  with 
the  same  tools  could  mix  and  lay  the  concrete  for  a 
bridge  or  a  nuclear  leactor  shield.  No  doubt 
problems,  such  as  delivering  the  concrete  to  the 
right  place  at  the  right  time,  could  be  solved,  so  it 


is  in  principle  feasible  In  practice,  the  bridge 
would  fall  down  and  the  reactor  .shield  leak  because 
the  quality  and  consistency  of  concrete  sufficient 
for  a  garden  path  would  not  be  .sufficient  for  a 
larger  structure. 

It  IS  so  with  software  Although  many  large 
systems  were  produced  in  assembly  code;  even 
more  were  attempted  but  never  used  because  their 
quality  was  too  low  The  size  and  sophistication  of 
the  systems  we  can  build  is  constrained  by  the  tiwls 
we  have  available. 

Tools  or  methods  for  producing  software, 
potentially  have  two  aspects. 

Chunkini;.  that  is  the  ability  to  ’see’ 
the  software  or  a  part  of  the  software 
as  a  small  enough  number  of  chunks 
to  be  understandable. 

Complexity:  that  is  the  connectivity 
between  the  chunks  is  of  low  enough 
complexity  to  be  understandable 

High  level  languages,  eg  FORTRAN  2,.  were  the 
first  t(x)ls,  they  enabled  a  number  of  machine  ctxle 
statements  to  be  created  by  one  high  level  language 
instruction.  Further  chunking  was  achieved  by  the 
concept  of  a  subroutine.  For  mathematical 
.software  that,  together  with  some  ad  hix:  rules  to 
control  complexity,  has  been  sufficient  to  produce 
large  systems  of  high  quality.  For  other  types  of 
software  this  was  necessary  but  not  sufficient.  New 
high  level  languages  such  as  PASCAL  and, 
following  that,.  Ada  were  devised.  These  give  more 
chunking  than  FORTRAN  permits  with  data 
structure  and  control  complexity  by  the  intnxJuction 
of  composite  data  ty|)es  which  can  be  manipulated 
as  a  whole  and  encouraging,  almost  enforcing, 
structured  programming  as  defined  by  Dijkstra  I  he 
methixJs  and  tools  di.sciissed  in  this  paper  take  these 
concepts  further 

There  are  a  number  of  methixis  which  have  evolved 
over  the  last  10  years  They  are  pioven,  in  that 
numerous  systems  have  been  developed  using  them, 
and  they  are  supportexi  by  Uxils,  available  in  the 
market  place,  which  can  themselves  be  regarded  as 
proven 

After  high  level  languages  the  next  step  was 
mixlular  programming,  initially  an  undefined  term 
until  Stevens,  Myers  and  Constantine  |3|  and 
Pamas  |4|  developed  the  following  qualities  which 
defined  a  gixxl  imxlule. 

High  cohesion  -  related  activities  art- 
grouped  together. 

Low  coupling  -  minimum  data 
transfer  between  imxiules 

Data  hiding  -  motiules  require  no 
(or  little)  knowledge  of  how  data  is 
.structured  in  other  mixlules 


1-3 


The  current  generation  of  methods  and  t(X)Is 
support  the  concepts  of  low  coupling  and  data 
hiding.  They  are  not  enforced,  so  it  is  po.ssiblc  to 
produce  a  poor  design;  but  their  use  is  encouraged. 
The  design  is  made  visible  in  the  diagrams  created 
by  the  tools,  so  it  is  easy  to  inspect  die  design  to 
di.scover  whether  it  is  of  sufficiently  high  quality. 

The  Yourdon  and  the  Mascot  methods  a.ssume  a 
'top  down'  design  process.  They  are,  for  reasons 
di.scu.ssed  in  paragraph  8,  le.s.s  good  at  supporting 
the  concept  of  high  cohesion. 

In  addition  to  the  aid  they  give  in  supporting  good 
design  principles,  the  tools  have  two  other  function 
which  affect  quality:  they  record  the  current  state 
of  the  design  and  a.ssist  with  reviewing  the  design. 
They  pre.sent  the  design  in  a  way  that  is  ea.sy  to 
understand  and  update  when  the  design  has  to 
change  becau.se  of  requirement  change  or 
implementation  considerations. 

For  many  companies  in  our  group  the  improvement 
in  documentation  and  design  control  brought  by  the 
design  tool  is  the  main  reason  for  using  the  twil. 
We  may  or  may  not  design  'top  down’:  we  do 
review  'top  down’. 

Since  the.se  methtnls  were  defined  ideas  on  .sy.stem 
development  have  evolved.  The.se  develop  further 
the  idea  of  a  module.  They  assume  that  a  sy.stem 
can  he  decomposed  into  a  number  of  objects. 

Object  is  a  technical  term.  It  means  a  piece  ol 
sottware  which  delivers  a  .service  when  requc-sted 
by  other  objects  but  who.se  internal  structuie  and 
data  IS  hidden  from  other  objects.  The.se  Object 
Oriented  Design  methods,  iri  effect,  enforce  the 
creation  of  modules  which  are  gtxKl  in  the  .sen.se 
described  above. 


5.  Current  Design  Methods  and  'Fools. 

Thiee  mcthiKls,  Yourdon,  Jack.son  System  Design 
and  Mascot  stem  the  most  popular  among.st 
designers  of  real  time  systems.  The  main  part  of 
each  .system  is  a  diagram  consisting  of  boxes  joined 
by  airows  thus:- 


Boxes  are  places  in  which  data  is  transformed. 
Arrows  are  routes  along  which  data  or  signals 
travel.  This  is  called  a  data  flow  diagram.  Each 
method  has  its  own  vocabulary  and  systems.  Some 
of  the  boxes  have  a  specialised  ftinction  and 
different  types  of  information  flow  are  marked  by 
some  device  such  as  double  arrows  or  dotted  lines. 


Two  of  the  methods  have  a  significant  feature: 
there  is  one  type  of  box  which  is  recursively 
defined.  That  is,  it  can  itself  contain  boxes  and 
arrows.  This  gives  great  chunking  power.  A  large 
.sy.stem  can  be  de-scribed  by  few  (le.s.s  than  10) 
boxes  with  arrows.  Each  box,  itself  containing 
further  boxes  and  arrows  and  .so  on  to  whatever 
level  of  detail  is  nece.ssary.  The  Jack.son  tools  tend 
not  to  support  this  feature.  jack.son  is  a  ’Middle 
out’  rather  than  a  top  down  method. 


Figure  2 


Fhe  methods  sunport  gootl  design  principles.  With 
one  exception,  di.scussed  below,  no  box  can  gel  at 
the  data  belonging  to  another  box,  except  via  the 
arrowed  routes,  using  the  appropriate  syntax  for 
that  route.  Thus,  the  Pamas  |4|  concept  of 
'inforination  hiding'  is  enforced  to  the  extent  that 
m)  box  can  change  the  data  held  by  another  box. 
Although  not  enlorced,  the  principle  of  low 
coupling  is  encouraged.  A  design  failing  to  meet 
this  criteria  would  have  too  many  arrows,  and  so 
be  recognisable  as  a  bad  design.  Composite  data 
ty(x:.s  are  supported  by  all  methods.  Only  data  of 
pre  defined  types  can  pass  along  the  arrowed 
routes.  Application  of  these  methods  using  pencil 
and  paper  would  be  difficult,  ttxils  are  nece.s.sary. 
They  maintain  a  data  base  of  the  design,  check  that 
each  arrow  both  starts  and  finishes  in  an 
appropriate  place,  and  pre,scrve  coasistency.  A 
most  important  feature  of  the  tools  is  that  when  a 
change  is  made  to  the  design,  they  bring  to  tlie 
attention  of  the  designer  the  coasequential  design 
changes  which  are  required. 

A  vital  feature  of  all  three  methods  is  that  they  all 
go  beyond  the  Von  Neuman  model  of  computing. 
The  mixes  operate  asynchronously.  That  is  each 
box  could,  in  principle,  be  a  separate  processor 
Thus,  in  the  early  part  of  the  work,  the  design  is 
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independent  of  the  detail  of  the  hardware  on  which 
the  system  will  run.  If,  when  implemented,  the 
system  runs  too  slowly,  the  same  design  can  be 
used  to  create  a  system  which  uses  more  or 
different  processors. 

In  the  Yourdon  Method  this  concept  of 
"implementation  free  design"  is  taken  further.  A 
designer  using  Yourdon  is  instructed  to  build  his 
data  flow  diagram  without  considering  how  data 
will  be  transferred  or  processed.  For  example,  a 
data  flow  might  well  be  "reactor  temperature  and 
pressure".  In  this  form  the  data  flow  diagram  is 
called  the  es.sential  model.  The  next  .stage  in  the 
desip  is  to  refine  the  essential  model  to  create  the 
implementation  model.  At  this  stage  data  types  are 
made  explicit  -  in  the  above  example  reactor 
temperature  might  be  defined  as  a  three  digit 
decimal  number.  The  transfer  medium  and  protocol 
would  also  be  defined.  This  distinction  between 
essential  and  implementation  models  is  a  feature  of 
the  Yourdon  Method.  The  other  methods  could  be 
used  that  way.  In  some,  perhaps  most,  situations 
the  distinction  is  valuable  -  details  of  the 
implementation  can  be  changed  without  affecting 
the  esseniial  model  and  the  designer  is 
concentrating  on  one  kind  of  thing  at  a  time.  In  the 
essential  model  he  is  working  on  what  has  to  be 
done:  in  the  implementation  nitKlel  he  concentrates 
on  how  It  will  be  done. 


6.  Full  Constituents  of  a  design  method. 

There  are  three  main  elements 

A  description  ol  how  the  system 
interfaces  with  its  environment. 

The  design  diagrams  -  (data  tlow 
diagrams) 

Translation  of  the  design  into  a 
coniputer  program. 

Prtxlucing  the  design  diagrams  is  the  cieative  part 
of  design  and  is  discus.sed  below  The  Jackson 
methixl  tor  the  other  two  activities  is  the  easiest  to 
describe.  Taking  the  translation  into  code  first.  The 
method  is  called  Jackson  System  Programming, 

\1\.  It  is  based  on  the  Ifijkstra  concepts  of 
structured  programming;  .sequence,  iteration  and 
selection  are  the  only  control  structures  permitted. 


It  uses  boxes  connected  as  follows.  They  form  a 
tree,  that  is  each  of  the  boxes  A,  B  and  C  can 
themselves  have  twxes  beneath  them  to  whatever 
depth  is  appropriate. 


Figure  3 


This  means  X  is  A  followed  by  B  followed  by  C. 


Figure  4 


This  means  X  is  either  A  or  B 


Figure  5 


And  this  is  X  is  A  then  a  number  of  Bs  followed 
by  C. 

'.'he  program  code  is  then  created  by  following 
through  the  tree  in  a  logical  order.  The  olher 
methods  go  through  a  similar  piocess  loi  code 
JSP,  Jackson  .System  Programming, was  the 
piecursoi  to  JSD.  A  majOi  step  in  the  creation  ol 
JSD  was  the  recognition  that  the  .sy.stems' 
interaction  with  its  environment  could  be  described 
using  a  similar  structure  to  that  of  JSP  The  data 
which  a  coinputei  system  prtKesses  can  be 
described  using  the  concepts  of  sequence,  iteration 
and  selection.  For  example,  a  data  .serjucnce  could 
lie  an  ’A’  followed  by  a  number  ot  ’B’s,  then  a  ’C" 
or  an  'A'  followed  by  either  a  'B'  or  a  'C,  then  a 
i>.  The  diagram  used  to  describe  the  data  input  to 
a  sy.stem  are  essentially  the  .same  as  those  used  to 
describe  proce.ssing  at  the  code  level  Although 
they  use  a  lather  different  method  from  JSP  to 
de.scribe  code,  users  of  the  Yourdon  method  are 
tending  to  use  the  JSD  method  of  describing  data 
inputs  from  a  systems'  environment. 
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7.  Differences  between  the  methods. 


Data  ttraam 


Differences  between  the  methods  are  apparent  in 
the  way  they  handle  information  flow  between 
processor  boxes.  The  essentials  are  summarised 
below. 

7. 1  Mascot. 

Of  the  three  methods  the  communications  are  mo.st 
well  defined  in  Mascot.  Nece.ssarily  .so,  for  Ma.scot 
originally  had  run  time  environment  as  well  as 
being  a  design  method.  No  activity  box  can 
communicate  directly  with  any  other  activity  box. 
Communication  is  via  an  IDA,  intercommunication 
data  area.  Originally  there  were  two  of  the.se. 
channel  and  pool,  the  current  version  of  MASCOT, 
MASCOT  .1  permits  more  complex  IDAs. 


Statt  vactor 
lupacilsn 


Figure  7 


Figure  6 


A  channel  is  a  buffered,  first  in,  first  out  .store. 
Such  facilities  are  common  to  other  methods.  This 
enables  activities  to  progress  a.synchronously.  The 
.sending  activity  can  send  it  down  to  the  channel 
then  continue  with  its  work.  The  receiving  activity 
collects  the  data  from  the  channel  when  it  is  ready 
to  do  .so. 

A  pool  is  mure  complex.  It  always  contains  some 
data.  A  number  of  activities  can  update  the 
information  held  by  the  pool.  A  number  of 
activities  can  read  the  data  in  the  pcxil.  The 
difference  between  a  channel  and  a  pool  is  that, 
data  is  destroyed  when  read  in  a  cliannel;  data 
remains  in  a  pool  until  overwritten.  A  full 
description  or  Mascot  is  in  reference  |5|. 

7.2  Jackson  System  Design. 

Like  MASCOT,  JSD  has  communication  methods 
which  enable  activities  to  progress  asynchronously. 
There  are  two  methods.  One,  called  a  data 
stream,  is  similar  to  a  MASCOT  channel.  The 
other  enables  one  activity  to  inspat  (but  not  write 
to)  the  state  vator  of  aiiother  activity.  This  is  die 
same  sort  of  facility  as  a  MASCOT  pcxil.  A  purist 
may  argue  that  it  seems  less  safe  but  the  facility 
can  be  used  to  create  an  activity  which  duplicates 
the  action  of  a  MASCOT  pool. 

With  a  data  stream  the  initiator  is  the  activity 


supplying  the  data.  The  activity  requiring  data 
initiates  a  .state  vector  inspection.  The  Jackson 
methcxls,  both  for  design  and  programming  are  in 
reference  |6|. 

7.3  Yourdon. 

This  method  has  a  philo.sophy  different  from  the 
other  two  methixls.  The  Yourdon  method 
di.stingiiishes  Iretwecn  different  kinds  of 
information.  There  are  two  kinds,  data  and  signals. 
Signals  announce  that  an  event  has  taken  place  or 
issue  a  command.  Yoiiidon  has  one  tvpc  of  data 
.store,  which  is  more  like  a  MASCOT  ptvjl  than  a 
channel,  although  the  effect  of  a  channel  can  be 
created  using  control  signals. 

D - Q  »•<.  <i« 
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Evnt  flow 


Flow  to  (tor* 


Figure  8 


The  facility  of  separating  control  signals  from  data 
IS  powerful.  It  is  enhanced  by  the  provision  of 
finite  state  machine  models  to  sort  out  the 
conseouences  of  complex  interactioas  between 
control  signals.  For  some  types  of  real  time 
systems  this  facility  alone  makes  Yourdon  the 
metiiod  of  choice. 


8.  Weakness  of  these  methods. 

A  top  down  design  methodology  assists  the 
designer  in  achieving  two  of  the  three  criteria  of 
good  design,  data  hiding  and  low  coupling.  It 
contributes  less  towards  the  aim  of  high  cohesion. 
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There  is  little  a.ssistance  to  the  designer  in 
identifying  and  implementing  modules  which 
provide  Common  services.  Especially  so  on  a  large 
project  when,  following  the  top  level  design,  the 
re.st  of  the  work  is  partitioned  amongst  a  numl>er  of 
different  designers.  A  middle  out  approach,  for  the 
rea.sons  given  below,  enables  a  balance  to  be  stnick 
between  low  coupling  and  high  cohesion,  it  does 
not  neccessarily  achieve  both. 

One  of  our  companies,  which  uses  the  Yourdon 
method,  finds  the  methods'  poor  support  f<  r  'high 
cohesion'  so  much  of  a  problem  that  they  have 
drastically  revi.sed  the  way  they  operate  the 
method.  They  make  little  use  of  the  I(K)I  as  a 
design  aid  because,  having  tried  to  use  it  that  way, 
they  found  that  they  were  creating  unsatisfactory 
designs.  The  problem  .seemed  to  be  that  the 
decomposition  of  the  .system  coming  from  the  top 
down  methodology  was  not  resulting  in  a  grxKl 
.system  The  top  level  diagrams  when  first  produced 
.seemed  satisfactory  but,  as  the  design  proceeded  to 
lower  levels,  and  the  designers  understanding  of 
what  was  necessary  improved,  the  design  became 
less  satisfactory.  Either  the  number  of  data  flows  in 
the  data  flow  diagrams  increased;  or  a  lot  of  similar 
things  were  done  in  different  parts  of  the  .system. 
Either  high  cohesion  or  low  coupling  could  be 
achieved,  hut  not  both.  Eor  the  kinds  of  system  this 
company  is  producing,  large  radar  sy.stems,  they 
find  that  a  better  design  route  is  to  identity  the  low 
level  modules  which  will  be  required.  The-se  aie 
then  put  into  groups,  then  groups  into  larger  groups 
and  .so  on.  Although  the  Yourdon  ttml  is  not  u.scd 
as  a  design  method;  it  is  used  to  record  the  design, 
maintain  it  as  the  requirement  evolves  and  to 
siipiHirt  design  review. 

This  is  the  ex()erience  of  one  company  in  our 
group,  .Some  other  companies  are  following  their 
lead.  Other  companies  find  the  top  down 
approach  satisfactoiy  for  the  kind  of  software  they 
produce,  so  use  the  tixils  both  as  a  design  aid  and  a 
methixl  of  reci'rdiiig  the  design. 

The  newer  methixls.  Object  Oriented  Design, 
pre.serve  the  advantages  of  current  metluxls  whilst 
encouraging  high  cohesion  They  are  discussed 
below. 


9.  Objected  Oriented  Methods. 

Although  not  entirely  a  new  idea,  their  precursor  - 
SIMULA  emerged  in  the  1960s,  Object  Oriented 
Metluxls  have  surged  in  popularity  in  recent  years. 
Smalltalk,  followed  by  C  t  I  have  contributed  at 
the  programming  level;  so  has  Ada  which  has  many 
of  the  features  of  an  object  oriented  language. 

The  Object  Oriented  approach  considers  a  .sy.siem  to 
be  a  .set  of  interacting  objects,  liach  object  piovides 
a  service  or  .services  to  other  objects.  Objects 
request  a  service  of  other  objects  by  .sending  a 
message  to  that  object,  A  me.ssage  consists  of  a 
request  foi  a  service  together  with  any  necessary 
data.  Objects  have  access  to  one  another  only  via 


messages.  This  is  the  heart  of  the  matter. 
Reference  18|  contains  a  full  description  of  object 
oriented  programming  including  tho.se  aspects  not 
covered  in  this  paper.  The.se  programming  ideas 
have  been  carried  into  the  requirement  capture  and 
design  part  of  the  life  cycle.  In  Europe  the 
development  of  HOOD,  hierarchical  object  oriented 
design,  by  the  European  Space  Agency  and  its 
adoption  by  the  European  Fighter  Aircraft 
con.sortium  have  .supported  and  encouraged  the 
move  towards  object  oriented  methods.  There  are 
now  at  lea.st  two  HOOD  t(X)l  sets  which  are  being 
sold  in  the  open  market  and  supported. 

Like  the  other  melhixis  discussed,  HOOD  has 
diagrams  with  boxes  and  arrows.  It  also  has  the 
recursive  principle,  that  is,  a  hox  can  it.self  contain 
boxes  and  arrows:  this  is  why  'hierarchical'  is  part 
of  its  title  But  the  HOOD  diagrams  are  not  data 
flow  diagrams,  the  arrows  indicate  which  objects 
use  the  services  of  other  objects.  In  HOOD  there 
are  four  different  message  types  and  two  different 
object  types  lo  proviile  the  synchronisation  and 
parallel  operation  required  in  a  high  performance 
real  time  system.  Such  detail  is  not  relevant  to  this 
paper,,  it  is  in  Relerence  jOj. 

A  Hood  Object 


Restriction  of  communications  lH;tween  iiuxlules  lo 
icquesis  for  service  is  a  (Xiwerful  concept.  Objects 
give  a  greater  amount  of  encapsulation  than  the 
pux:essor  boxes  in  other  methixls;  so,  once  its 
services  have  been  dermed,  the  design  and 
implementation  of  an  object  can  be  carried  out 
independently  of  the  rest  of  the  project  It  retains 
and  reinforces  the  gams  made  by  earlier  methtxls  in 
ilata  hiding  and  low  coupling  and  the  designer 
naturally  tends  to  put  related  services  in  the  same 
object.  It  therefore  supports  high  cohesion  and  .so 
adds  to  the  gains  in  quality  provided  by  earlier 
methixls. 

An  additional  advantage  of  object  oriented  metluxls 
IS  that  they  promote  software  reuse.  I'he 
encapsulation  provided  by  the  concept  of  an  object 
is  so  strong  that  it  enables  objects  to  be  transferred 
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from  one  project  to  another  unchanged  if  they 
provide  appropriate  services.  If  changes  have  to  be 
made  the  change  proce.ss  is  controllable,  as  it  is 
restricted  to  changing  the  services  provided  by  the 
object. 


10.  Formal  Methods  in  Requirements  and 
Design. 

It  has  been  known  for  more  than  ten  years  that  the 
requirement  for  a  computer  system  can,  in 
principle,  he  encapsulated  in  a  formal  mathematical 
language.  The  requirement  can  then  he  proven 
complete  and  consistent  Further,  the 
transformation  to  design  and  code  can  al.so  be.  in 
principle,  formalised  to  ensure  that  the  eventual 
code  IS  proven  to  instantiate  the  requirement.  This 
is  most  attractive  It  suggests  the  pt'ssibility  ol 
proving  that  progiams  are  correct  Testing  does  not 
do  this,  at  be, St  testing  pioves  that  the  software  is 
not  incorrect  in  the  aspect  which  is  being  tested 
Yet,  in  practice,  formal  inethtHls  are  rarely  used. 
Many  reasons  have  been  advanced  to  explain  this. 
Fiom  the  point  ot  view  of  this  paper  the  relevant 
reason  is  that  of  scaling  Formal  mclhods  woik 
well  for  .small  .systems  but  the  time  and  cllort 
required  to  apply  formal  melhtnls  seems  not  to  have 
a  linear  relationship  with  .system  si/e,  it  inciea.ses 
much  mole  lapidly 

Cuiicnt  ilesign  methods  give  the  designer  gieat 
fieedom  in  the  way  he  chtaises  to  decomjxi.se  the 
.system  into  activities  and  data  Hows  so,  if  lornial 
methods  are  to  be  a(iplied,  they  have  to  be  applied 


to  the  whole  sy.stem  as  a  single  entity.  At  the 
current  state  of  development  of  formal  methods  that 
is,  in  practice,  impossible. 

In  an  Object  Oriented  Design  the  objects  have  more 
.solid  boundaries  and  communication  between  them 
is  more  formalised  than  activities  and  the 
communication  between  them  in  current  methods. 
This  ameliorates  the  scaling  problem.  An  object 
could  be  proven  correct  independently  of  the  rest  of 
the  sy.stem.  Then,  since  the  inside  of  an  object  is 
hidden,  a  system  or  subsystem  could  be  proven  as  a 
set  of  interacting  objects. 


11.  Summary  and  Conclusion. 

Software  Quality  is  to  a  large  extent  determined  by 
how  well  the  developers  follow  the  principle  of 
Data  Hiding,  Low  Coupling  and  High  Cohesion. 
Current  design  Uxils  provide  gtxHl  support  for  the 
Inst  two  ot  these  concepts;  support  for  high 
cohesion  is  le.ss  gtHKi  The  newer  methwls,  ba.sed 
on  object  orienled  principles,  retain  the  advantages 
gained  by  current  methiHls  and  support  high 
cohesion. 

Formal  inethixls.  which  to  date  have  promised 
much  moie  than  they  have  produced,  may  gain  a 
new  lease  of  life  as  object  oriented  inelluxis 
become  more  ixipular.  The  giealer  encapsulation 
provided  by  these  methods  may  make  the  use  of 
iormal  metlxxls  feasible  on  quite  reasonably  si/ed 
systems. 
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EFA  is  a  aultinational  pro3ect.  As  to  pertinent  data  processing  support,  agreeaent  had  to  be  reached 
between  the  partner  nations  (both  industry  and  government)  The  paper  will  show  that,  generally  agreements 
were  worAed  out  by  arriving  at  the  lowest  common  denominator  since  none  of  the  participating  nations  was 
prepared  to  accept  standards  established  by  another  partner  nation,  which  would  have  meant  giving  up  its 
own  standard. 

The  paper  will  address  important  additional  information  as  well  as  experience  gained  to  date: 

*  some  general  information  on  the  EFA  Project,  including  important  determinations  made 

*  the  status  of  the  software  tool  selection  and  procurement  in  the  EFA  Project 

*  a  comparison  between  required  and  actual  availability  of  software  tools  in  the  EFA  Project 

The  paper  will  conclude  by  trying  to  point  out  what  could  be  done  in  order  to  preclude  the  problems 
mentioned. 


1.  umainqty  ebbms 

EFA  IS  a  multinational  project.  As  to 
pertinent  data  processing  support,  one  could 
therefore  not  simply  apply  national  standards  and 
procedures.  Rather,  agreement  had  to  be  reached 
between  the  partner  nations  (both  industry  and 
government) . 

The  following  will  show  thit  important 
determinations  have  betn  made  within  the 
multinational  framework  at  a  very  early  stage. 
However,  these  were  generally  agreements  worked 
out  by  arriving  at  the  lowest  common  denominator 
since  none  of  the  participating  nations  was 
prepared  to  accept  standards  established  by 
another  partner  nation  which  would  have  meant 
giving  up  its  own  standard.  Later  on,  I  an  going 
to  describe  what  comes  of  such  a  course  of  action. 

Since  these  facts  alone  are  not  very 
meaningful,  I  will  address  important  additional 
information  as  w*ll  as  experience  gained  to  date. 
To  begin  with,  I  am  going  to  offer  some  general 
information  on  the  EFA  Project,,  including 
important  determinations  made,  following  that,  I 
will  explain  the  status  of  the  software  tool 
selection  and  procurement  in  the  project.  After 
drawing  a  comparison  between  required  and  actual 
availability  of  software  tools,  I  will  conclude  by 
trying  to  point  out  what  could  be  done  in  order  to 
preclude  the  problems  mentioned. 

2.  RRanRBUS  m.'!tM.Tg«n  my  T«  MifflCWS 

2.1  Kictaam 

EFA  13  a  quadrinational  programme  which  is 
jointly  carried  out  by  the  United  Kingdom,  Italy, 
Spain  and  Germany.  Early  on,  France  had  also 
participated  in  the  programme. 

Due  to  the  fact  that  the  United  Kingdom, 
Italy  and  Germany  have  been  implementing  the 
Tornado  Programme  together,  the  course  of  the  EFA 
Project  has  already  been  set  to  a  certain  degree, 
which  also  shows  in  formulations  of  the  earliest 
documents. 


The  requirements  to  be  net  by  the  development 
tools  have  been  considerably  influenced  by 
Tornado.  What  had  been  agreed  on  trinationally, 
was  now  agreed  by  five  nations  or  four,, 
respectively. 

2.2  EUKHWISTAlTTAIKaT  (EST.  11.10.84) 

The  E5R  formulations  have  been  kept  in  fair)'/ 
general  terns  and,  actually  require  only 

*  in  para  4.2.1  the  use  of  a  High  Order 
Language,  and 

*  in  para  6.2.1  the  use  of  development  tools. 

Para  4.2.1 

"The  coaaon  use  of  a  High  Order  Language  and 
a  Bus-System  is  required. " 

Annex  Q  of  the  EST  lists  the  following  detail 
requirements: 

*  while  France  demands  LTR 

*  the  other  nations  call  for  Ada,  and 

*  the  United  Kingdom  also  for  Coral  66. 

Para  6.2.1 

"To  build  confidence  in  the  ultimate  quality 
of  the  hardvare/softeare  system  the  contractor  is 
to  subait  a  detailed  proposal  for  a  System 
Developaent  Environaent  (SDE)  for  approval  before 
installation.  This  should  cover  the  following 
aspects; 

*  codes  of  practice 

*  software  tools 

*  test  and  integration 

*  use  of  language 

a  docuaentation  standards. " 

2.3  EUMPEIII  STMT  RtDUmBBir  (ESR.  09.12.85) 

In  the  next  phase  (meanwhile  without  France) , 
the  formulations  become  considerably  more  precise: 

a  Ada  IS  the  preferred  High  Order  Language 

a  In  case  of  non-availability  of  an  Ada 
Programming  Support  Environment  (APSE) , 
CORE/EPOS,  a  combination  of  tools,  which 
had  been  agreed  on  in  the  case  of  Tornado, 
should  be  used. 


Para  6. 3. 2.1 

"Softffare  is  to  be  written  in  the  HOL  Ada 
throughout:  exceptions  aay  be  aade  in  particular 
areas  ...  all  such  exceptions  are  to  be  agreed 
with  the  Air  Staffs.  " 

Para  6.3,3 

"To  build  confidence  in  the  ultiaate  quality 
of  the  hardware  and  software  system  and  the 
related  documentation  the  contractor  is  to  submt 
a  detailed  proposal  for  a  System  Development 
Environment'  (SDE)  for  approval  by  the  nations. 
This  IS  to  cover  the  following  aspects: 

*  standards  and  procedures 

*  software  tools  and  methods 

*  use  of  language 

*  ... . " 

Para  6. 3. 3.1 

"In  the  absence  of  a  fell  Ada  Programmng 
Support  Environnent  (APSE)  an  EPOS/CORE  system  for 
all  aspects  related  to: 

*  design  and  development 

*  project  management 

*  configuration  management 

*  computer  generated  software  documentation 

*  ...  . " 

2.4  Euemii  siMT  pgamaworr  ct  mmanair  (bsr-d. 

19.09.871 

Now,,  the  fornulatione  are  beconing 

*  more  precise  on  the  one  hand 
It  IS  stated 

-  when  exceptions  to  usin«  Ada  are 

petnitted,  and 

-  who  has  to  approve  the  waiver  (the 
Nations,  rather  than  the  Air  Staffs) 

*  and  nore  cautious  on  the  other  hand.. 

as  to  the  developaent  tools,  there  is  only 
in  case  of  non-availahility  of  an  Ada 
Piojranaing  Support  Environient  a  require- 
nent  that  a  tool  conbination  be  used  like 
the  one  which  had  been  agreed  on  in  the 
case  of  Tornado  (CORE/EPOS), 

Para  6. 3. 2. I 

"Software  is  to  be  written  in  an  HOL.  For  all 
systeas  Ada  shall  be  used,,  restrictions  on  the  use 
of  Ada  or  some  of  its  features  will  have  to  be 
agreed  between  Industry  and  nations.'' 

Para  6.3.3 

"To  build  confidence  in  the  ultimate  quality 
of  the  hardware  and  software  system  and  the 
related  documentation  the  contractor  is  to  submit 
a  detailed  proposal  for  a  Systea  Development 
Environment  (SDE)  for  approval  by  the  nations. 
This  IS  to  cover  the  following  aspects: 

‘  standards  and  procedures 

<  software  tools  and  methods 

*  use  of  language 

*  ...  . " 

Para  6. 3. 3.1 

"In  the  absence  of  a  full  Ada  Programming 
Support  Environment  (APSE)  the  SDE  concept  shall 
be  based  on  the  use  of  tools  such  as  CORE/EPOS  for 
all  aspects  related  to: 

•  system  requirement  specifications/interface 
specifications 

•  design  and  development 

•  configuration  management 

•  computer  generated  software  documentation. " 


2.5  WEAPW  SYSIBI  BESIOf  AW)  PHffqiHHCg  SPBTTWamat 

(NSDPS.  01.10.88) 

The  NSDPS  -  the  developaent  contract 
technical  specification  -  does  not  directly 
specify  the  tools  to  be  used.  Rather,,  it  says 
under  "Software  Design  Principles" 

Para  1,3. 4.1 

"Software  shall  be  designed  and  developed 
using  the  SDE  (see  part  III,,  para  2.6.6)" 

and  there,,  the  following  is  stated: 

Para  2.6.6 

"The  SDE  shall  provide  a  complete  environment 
for  system/software  design  and  development. 

It  comprises: 

a.  CORE/EPOS  and  other  tools  agreed  by  the 
customer  to  be  used  for  system/software 
design  and  documentation. 

b.  Configuration  Management  and  Modifica¬ 
tion  procedures  and  tools...  . 

c.  EFA  Software  Standards  . . . 

d.  Programme  support  environment  for  Ada 
and  any  other  language  . . . 

e  The  tools/software  to  support  software 
verification,,  testing,,  integration,, 
validation  and  certification  (including 
analysis  tools). 

f.  Generation  of  design  documentation  and 
cross  refetence  between  documentation 
levels. " 

While  industry  has  thus  to  propose  the  tools 
to  be  used,,  the  Nations  -  particularly  because  of 
the  influence  on  the  in-service  phase  (Software 
Maintenance)  -  will  have  to  accept  that  proposal. 

2.6  P81MKT  SPHCmCS 

Before  addressing  data  processing  details 
regarding  the  EFA  Proiect,  let  ne  aention  a  few 
project  specifics. 

The  coapanies  Eurofighter  (EF)  for  the 
aircraft  and  Eurojct  (EJ)  for  the  engine  are 
consortia  torned  by  national  coopanies.  In  the 
following,.  I  restrict  nyself  to  the  aircraft 
consortiun,  the  Eurofighter  Coapany,  which  is  made 
up  of  the  following  national  coapanies: 

*  Alenia  (Italy) 

*  BAe  (United  Kingdon) 

*  CASA  (Spam)  and 

*  MBB/Dornier  (Gernany) . 

Each  Eurofighter  Partner  Coapany  (EPC)  is 
within  EF  responsible  (Systea  Design  Responsible 
Coapany  =  SDR  Coapany),  for  specific  tasks.  Joint 
Teaas  consisting  of  personnel  of  all  coapanies  (in 
the  ease  of  avionic  design  such  as  the  Avionic 
Joint  Teaa  (AvJT)  based  with  BAe  at  Warton,  which 
IS  also  the  leading  office  for  all  data  processing 
aatters)  were  foraed  which  are  responsible  for  the 
design  of  the  various  EFA  systeas. 

There  is  an  laportant  project  characteristic 
in  that  all.  docvaents  (for  exaaple,  also  tender 
specifications)  prepared  by  the  SDR  Coapany  or  the 
responsible  teaa,,  have  to  be  endorsed  by  the  other 
coapanies,  that  is,  having  been  prepared,  they  are 
forwarded  to  the  partner  coapanies  for  coaaents. 
Subsequently,  Eurofighter  Co.  aust  approve  and 
issue  the  docuaents. 
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This  course  ol  action  is  very  tise-consuBinj 
and  It  has  happened  that  a  report  took  nearly  one 
year  after  preparation  to  arrive  at  the  Nations 
and  at  NEFMA  (our  "NATO  EFA  Development, 
Production  and  Logistic  Management  Agency").  One 
reason  for  that  procedure  may  well  be  that  each 
EPC  wants  "to  have  a  say"  in  each  area  -  among 
other  things,,  because  of  the  national 
responsibility  vis-i-vis  its  own  government  -  and 
that  the  EPC  is  probably  expected  to  do  that  on 
account  of  requirements  established  by  the 
respective  nations. 

3.  snacncH  aw  pwaiaiBfr  or  sonwiii  Totia 

Work  on  EFA  data  processing  aspects  between 
the  Nations,,  including  NEFMA,  and  industry  is  done 
in  the  Systems  Integration  and  Software  Croup 
(SISG)  which  held  its  first  meeting  from  17  to  19 
September  1986,  that  is,  more  than  two  years 
before  the  development  contract  was  signed. 

3.1  PKBXlpmCMS 

Initially,  basic  matters  had  to  be  clarified 
and  settled  before  the  actual  selection  and 
procurement  of  tools  could  be  tackled. 

3.1.1  pgjcy  STMTiwr 

The  first  activity  engaged  in  by  the  data 
processing  specialists  of  the  four  nations  (from 
both,  government  and  industry)  was  to  determine 
data  processing  guidelines,  according  to  which 
system/software  design  and  development  was  to  be 
accomplished.  By  the  spring  of  1987,  a  Policy 
Statement  had  been  prepared  and  agreed,,  which, 
among  other  things,  specified 

*  Us  applicability  to  specific  software 
Items  (that  is,  aij,  those  required  for  the 
Weapons  system  and  the  weapon^  system 
development) . 

*  which  significant  management  tools  (plaits, 
documents)  were  to  be  prepared  (detailed 
plans  in  accordance  with  the  EFA  Software 
Standards) ,  and 

*  on  which  standards  these  management  tools 
were  to  be  based  (agreement  was  reached 
that  system/software  design  and  development 
be  execv*ed  in  accordance  with  DoD-STD-2167 
thereby  taking  into  account  RTCA-DO  17S/A). 

3.1.2  EFA  scrnwtE  samuttis 

In  line  with  the  above  determination  and 
subsequent  to  the  Policy  Statement  whereby  the 
latter's  requirements  are  taken  into  account,  the 
EFA  Software  Standards  were  established  beginni,-ig 
in  spring  1987.  They  must  be  applied  to  all 
software  including  equipment  software  and  by  all 
equipment  suppliers.  Since  1939/1990,  these 
standards  have  be'‘n  available  as  binding  Progect 
Standards,  and  they  also  define 

*  the  course  of  action  to  be  taken  by  the 
software  configurations  management  in  the 
Eurofighter  Software  Configuration  Manage¬ 
ment  Plan  (PL-J-019-E-1003)  (SCMP,  Issue  1 
of  March  1989) 

*  the  development  documents  to  be  prepared, 
as  well  as  the  course  of  action  to  be  taken 
in  software  development  and  certification, 
including  software  safety,  in  the 


Eurofighter  Software  Development  Standard 
(PL-J-019-E-1006)  (SDS,  Issue  1  of  March 
1990)) 

*  the  use  of  tools  agreed  in  the  Eurofighter 
Software  Methods  and  Tools  Applications 
Standard  (PL-J-019-E-1010)  (SMTAS).  This 
document  will  be  prepared  according  to  the 
project  progress  made.  While  the  pertinent 
parts  for  System  Design  (Annex  A)  and 
Software  Design  (Annex  B)  have  been 
available  so  far  as  Issue  2  of  June  1990, 
we  are  still  waiting  for  the  first  drafts 
for  Software  Coding  (Annex  C)  and  Software 
Testing  (Annex  D) , 

*  the  documentation  of  software  development 
in  the  EFA  Software  Documentation  Standard 
(PL-J-019-E-1011)  (SDOS,  Issue  2  of  March 
1990). This  standard  contains  -  in  annexes  - 
the  model  texts  for  the  documents  to  be 
prepared  according  to  the  SDS.  These  model 
texts  are  prepared  according  to  the  project 
progress  made.  At  this  point  in  time,  about 
76  percent  of  them  are  available. 

3.1.3  HKS  ORna  LAIKMWat 

Right  from  the  start  the  requirement  was 
established  by  the  participating  Nations  to  use  a 
High  Order  Language  (HoL) ,  and  also  which  one  - 
namely,  Ada.  In  line  with  that  determination,  and 
beginning  in  1987,  that  is,  parallel  with  the  EFA 
Software  Standards,  another  Policy  Statement  was 
prepared  by  data  processing  specialists  of  the 
four  nations  (from  both  government  an^  industry), 
which  addresses  the  Ada  compiler.  With  that  Policy 
Statement,  entitled  "The  use  of  Ada  Compilers  in 
the  EFA  Project"  and  dated  10  February  1988,  among 
other  things 

*  selection  (procedure) 

*  development  (course  of  action) 

*  validation  matters,  and 

‘  use  (updates,  version  control) 
were  determined. 

It  was  an  important  task  lor  the  System 
Integration  and  Software  Group  to  decide  which 
compiler  should  be  used.  Prior  to  that,  however,  a 
decision  had  to  be  made  as  to  which  (i-processor 
should  be  used  and  which  measures  were  to  be  taken 
in  order  to  meet  the  reliability  requirements  for 
flight  safety  critical  software. 

In  early  1983  Eurofighter  Co.  presented  a 
study  entitled  "The  Use  of  Ada  for  Safety  Critical 
Applications" . 

This  study  demonstrated  that  Ada  can  be  used 
for  aU  safety  critical  applications.  The 
reliability  of  Ada  programs  is  comparable  to  that 
of  assembler  programs,  if  not  greater,  if 

*  any  restriction  on  the  use  of  the  Ada 
language  is  strictly  adhered  to  (Safe  Ada), 
and 

*  the  static  code  analysis  at  source  code 
level  (^  Ada)  is  made. 

Any  reliability  problems  have  been  mainly 
seen  in  the  compiler  area.  In  order  to  preclude 
any  possible  compilation  error  as  well  as 
unforeseeable  run-time  behavior,  a  certain 
restriction  on  tne  use  of  the  Ada  language  was 
agreed,  together  with  initial  target  code 
verification. 


2-4 


2.1.4  SnWMO  u-PMCBSCR 

In  early  1988,  Eurofighter  Co.  presented  the 
results  of  a  narket  survey  in  the  fora  of  a  p- 
Processor  Report.  In  it,  the  Motorola 
HC68020/68881  was  proposed  to  become  the  standard 
p-processor  for  the  EPA  Project. 

This  p-processor  (and  this  is  why  we  speak  of 
a  "standard  p-processor")  will  invariably  be  used 
by  all  subcontractors,  that  is,  only  one 
prograaning  environient  (conpiler,  run-time 
System,  debugger,,  etc.)  is  required  for  the 
project. 

Eurofighter  and  Motorola  have  yet  to  agree  on 
a  conditions,  in  which  Motorola  Co.  would,  among 
other  things,  guarantee 

*  supportability  for  a  period  of  25  years, 
beginning  on  the  date  the  last  aircraft 
enters  into  service,,  and 

*  enhanced  radiation  hardening. 

In  this  connection,  the  main  problem  is  that 
Motorola  Co.  is  not  prepared  (and  probably  just 
cannot  guarantee)  that  some  years  from  now,  the 
required  production  would  still  be  based  on  the 
old  technologies  and  old  masks,  when  -  in  the 
meantime  -  production  would  have  been  modernized 
and  the  masks  reduced  in  size. 


SDE  includes  tools  for 

*  system  design 

'  software  design/development 

*  Ada  compiler,  and 

■  static  and  dynamic  teat  tools 
as  well  as 

*  IPSE  with  Its  standard  tools. 


TOI^  TO  SWTW  DE 


The  basic  weapon  system  performance 
requirements  had  been  known  to  industry  already 
with  the  first  phase  documents,  that  is,  very 
early.  And  the  same  documents  also  specified  the 
tools  to  be  used  for  weapons  system  design  and 
development:  CORE  and  EPOS.  They  could  certainly 
have  been  used  also  in  the  early  stages  of  the 
project  in  a  meaningful  way. 


called  CORE-EPOS  transformer,  still  had  to  be 
developed.  The  contract  for  that  development  was 
awarded  in  October  1988. 


TOCLS  CT  SCraiARg  DE 


As  to  software  design  and  development  tools, 
industry  had  conducted  a  narket  survey  in  1987/88. 
An  important  task  to  be  performed  by  that  narket 
survey  was  to  determine  the  method  to  be  used  for 
software  development.  Following  an  analysis  of  the 
docunents/proposals  received,  Eurofighter  Co. 
recommended  the  Hierarchical  Object  Oriented 
Design,  in  short  ROOD,  to  the  Nations  as  method  to 
be  used  for  software  development. 


Here  again,  the  narket  survey  had  shown  that 
the  Cools  required  were  QOt  yet  available  in  the 
configuration  required  by  the  project.  Making  use 
of  the  resul.s  of  the  narket  survey,  a  tender 
specification  was  prepared  and  -  following 
evaluation  of  the  proposals  -  in  November  1989  the 
British  company  Integra  Software  (IPSVS)  PLC  (on 
behalf  of  Software  Sciences)  was  awarded  the 
contract  to  supply  its  "H(X)D  Toolset"  as  Hood 
tool . 


Adaptation  developments  were  also  required  in 
the  following  areas: 

*  traceability  Co  CORE/EPOS  and  vice  versa 

*  Ada  code  extraction 

*  security  classification  attribute  for 
objects  and  its  printout  on  documents  and 
diagrams. 


3.2.3  APA-CanUBt 

The  Project  Baselined  Compiler  to  be  employed 
according  Co  the  Policy  Statement  will  be  procured 
by  both  Eurofighter  and  Eurojet,  and  its  use  by 
the  equipment  suppliers  -  that  is,  for  those  who 
need  it  -  has  been  ensurad. 

As  to  the  Ada  Compiler,  industry  conducted  a 
market  survey  in  1987/38,  whose  results  were 
incorporated  into  the  tender  specification. 
Subsequent  to  the  request  for  proposal  in  early 
1989  and  their  evaluation,  the  contract  was 
awarded  in  February  1990  to  SD-Scicon  Company  for 
XD-Ada 


Whereas  EPOS  is  mainly  used 

*  to  analyze  and  identify  individual 

requirements  from  "plain  english"  texts 

*  to  ensure  requirement  traceability 

*  Co  compile  the  Interface  Requirement 
Documents 

CORE  IS  mainly  used  for  the  design  process, 
i.e.  to  decompose  high  level  requirements  in  a 
logical  and  consistent  manner  until  a  level  is 
reached  where  the  requirements  are  expressed  in 
such  sufficiently,  precise  detail  to  allow 
software  design  to  begin. 

Already  on  21  October  1985,  industry  thus 
stated  in  a  restrictive  manner; 

"It  IS  anticipated  that  full  facilities,  both 
hardware  and  software,,  allomng  direct  entry  from 
EPOS  to  CORE  eill  be  available  to  aJ!  partners  not 
before  August  1986. " 

The  reason  for  this  restriction  was  that  the 
interface  routines  between  the  existing  tools  CORE 
(BAe  Company)  and  EPOS  (GPP  Company),  the  so- 


Adaptaticn  developments  were  also  required  in 
the  following  areas: 

*  Target  Run  Time  System  for  multi-p- 
processor  systems 

*  emulation  of  basic  floating  point 

operations  (in  case  no  mathematical  co¬ 
processor  IS  used) 

*  library  of  mathematical  fixed  and  floating 
point  functions. 

3.2.4  STinc  AND  DYimC  TEST  TOCLS 

As  already  shown,  the  reliability  of  Ada 

programs  -  where  compiler  errors  are  critical, 
rather  than  programming  errors  -  is  comparable  to 
that  of  assembler  programs,  if  not  greater, 
provided  that 

*  any  restriction  on  the  use  of  the  Ada 

language  is  strictly  adhered  to  (Safe  Ada), 
and  that 

*  the  static  code  analysis  at  source  code 

level  (-  Ada)  is  made. 

As  said  before,  target  code  verification  will 
be  applied  as  long  as  the  compiler  stability  has 
not  been  proven. 
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Thus,  Khen  testing,  appropriate  tools  must  be 
used  to  check  whether  the  progranner  has  observed 
the  restrictions  agreed. 

While  the  SPARK  Exaniner  (by  FVL)  is  used  to 
make  the  static  code  analysis,.  TESTBED  (by 
Liverpool  Data  Research  Limited  (LDRA))  is  used 
for  the  dynamic  analysis.  These  tools,  however, 
are  only  required  to  be  used  for  "Risk  Class  1 
Software",,  that  is,.  Flight  Safety  Critical 
Software. 

The  license  agreements  for  these  "off  the 
shelf"  tools  were  signed  in  mid  1990,  following  a 
market  survey. 

3.2.5  mnoaiB) prograiwib  sutot nmioiwr  (ipse) 

The  aim  had  been  to  find  an  Integrated 
Programming  Support  Environment,  into  which 
possibly  all  of  these  tools  listed  under 
paragraphs  3.2.1  through  3.2.4  could  be 
integrated.  In  add.tion,  it  was  to  include 
standard  tools,  such  as  those  for 

*  documentation 

«  configuration  control. 

As  to  the  Integrated  Programming  Support 
Environment,  industry  had  conducted  an  initial 
market  survey  at  the  end  of  1987/in  early  1988,  to 
be  followed  later  by  the  request  for  proposals.  In 
the  spring  of  1990,  Eurofighter  Co.  selected  the 
tool  "Perspective",  offered  by  the  British  company 
System  Designers.  Since  significant  parts  of  the 
IPSE  were  not  available  as  required,  here  again,  a 
contract  had  to  be  awarded  for  adaptation 
developments  also  in  the  following  areas: 

*  user  interface  (format  of  terminal  windows) 

*  data  management  facilities 

a  database  protection  facilities 

*  configuration  control 

*  integration  of  the  interface  control  tool 
"Ingres". 

4.  AVAMBlLnV  VERSUS  RIMRBWTS 
4.1  GBWAL 

As  can  be  seen  from  the  observations,,  the 
entire  system  and  software  design  and  development 
of  the  EFA  Progect  was  to  be  earned  out  tool- 
supported  and  top-down.  In  this  connection,  a 
distinction  is  being  made  between  tools  for 

*  system  design 

*  software  design 

*  compiler,  as  well  as  for 

*  miscellaneous  purposes,  such  as  standards, 
test  tools  and  IPSE. 

Regarding  all  these  tools,  a  decision  has 
been  taken  in  the  meantime  as  to  what  is  to  be 
used  by  the  aircraft  consortium  (EF)  and  its 
equipment  suppliers,  namely 

*  CORE/EPOS  for  system  design 

*  the  HOOD  Toolset  by  IPSKS  for  software 
design 

*  SPARK  Examiner  by  PVL  for  static  code 
analyses 

t  TESTBED  by  LDRA  for  dynamic  tests/Analyses 

*  XD-Ada  by  SD-Scicon  as  Ada  compiler 

«  IPSE  by  System  Designers  based  on 
Perspective. 


4.2  T«  TOag  »  DEBOL 

Let  me  now  reverse  the  above  sequence,  that 
is,  start  with  IPSE  and  finish  with  the  CORE/EPOS 
system  design  tools. 

4.2.1  IPSE 

An  initial  version  of  IPSE  should  have  been 
available  in  autumn  1990,,  but  the  acceptance  tests 
for  this  version  failed  because  of  problems 
maintaining  database  integrity  due  to  hardware 
problems.  It  was  planned,  that  IPSE  should  be 
available  in  its  entirety  about  mid  1991  but  this 
will  no  longer  be  possible.  Nevertheless,  while 
this  is  not  the  optimum,,  it  will  not  result  in  any 
significant  problems  or  delays  in  the  programme 
especially  as  the  IPSE  is  only  used  by  the  EPCs. 

4.2.2  SIKTIC  AH)  DYMMC  TEST  TCOg 

furrently  available  versions  of  these  test 
tools  (SPARK  Examiner  and  TESTBED)  have  been 
available  since  November  1990.  This  seems  to  be 
fully  sufficient  since  the  software  tests  -  even 
those  conducted  by  equipment  suppliers  -  did  not 
begin  before  late  1990.  Updates  of  these 
commercially  available  tools  are  required. 

4.2.3  T«  ADA  carnal 

First  versions  of  the  Ada  Compiler  have  been 
available  since  May  1990  for  the  standard  p- 
procGssor.  In  its  entirety  it  will  be  available 
about  12  months  later.  This  is  fully  sufficient 
since  the  equipment  suppliers  started  coding  not 
before  the  middle  of  1990,,  and  since  the  compiler 
versions  available  at  that  time  had  been 
sufficient  (or  the  initial  work. 

4.2.4  HOOD-TOa. 

While  first  versions  of  the  HOOD  Tool  have 
been  available  since  December  1989,  it  will  be 
available  in  its  entirety  in  the  middle  of  1991. 
Here  again,  the  tool  has  been  available  in  good 
time  (or  the  development  of  both  aircraft  and 
equipment  software. 

4.2.5  CORE/EPOS 

Even  though  the  CORE  and  EPOS  tools  had 
already  been  released  since  198T  for  project  use, 
their  actual  use  had  been  limited  since  the  CORE- 
EPOS  transformer  -  lUst  like  the  associated 
versions  of  COKE  and  EPOS  -  could  not.  be  used. 

The  development,,  which  was  started  in 

October  1988,  had  taken  much  longer  than  was 
expected  in  the  Eurofighter  letter  referred  to 
earlier.  It  was  not  until  the  16th  meeting  of  the 
Systems  Integration  and  Siftware  Group  held  on 
12/13  November  1990  that  industry  reported 
"now  the  traosCoraei  cia  be  successfully  used  on 
the  project". 

But  due  to  the  necessary  paperwork  its 
release  for  use  on  the  proiect  only  took  place  in 
early  December  1990. 

4. 2. 5.1  RiasciB  tot  U«i!  aVATlAim.m 

The  first  quadrilateral  document,  the  ESR, 
was  signed  in  late  1985.  This  was  the  beginning  of 
the  leittt  definition  phase.  However,  some  time 
passed  -  although  the  participating  nations  and 
industry  bad  reached  early  agreement  on  the 
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tools  -  until  CORE/EPOS,  and  even  parts  of  then, 
had  been  available  to  all  developnent  teass  of  the 
aircraft  cospaniss,.  to  say  nothing  of  the  sub¬ 
contractors.  Apart  froa  the  inpleaentation  of 
desired/reguired  -  but  as  yet  not  released  - 
reguireaents,  there  Here  also  general  coaaercial 
issues  that  hindered  the  rapid  use  of  the  tools  by 
all  participants,  such  as 

*  individual  or  project  license 

*  which  version 

*  how  aany  "systeas”  per  coapany 

‘  how  aany  users  per  "system". 

Regarding  the  EPA  project,  industry  has  thus 
HorXed  for  a  long  tiae  either  without  the  tools  or 
with  the  tools,,  but  only  to  a  very  liaited  extent. 

4. 2. 5. 2  THE  CWaPWOS  Of  UTE  AVAIUlBlIJTy 

According  to  the  basic  documents,  such  as 
EST,  ESR,  ESR-0  and  VSDPS,  the  whole  system  design 
should  have  been  carried  out  tool-supported  and 
top-down;  that  is,  aU  concept  and  definition  work 
should  have  already  been  accoaplished  with  data 
processing  support.  This,  however,  was  not  the 
case. 

The  technical  reguireaents  to  be  met  by  the 
weapon  systea  were  laid  down  in  the  Veapon  Systea 
Design  and  Perforaance  Specification;  naturally, 
in  "plain  language"  since  this  was  an  annex  to  the 
earn  developaent  contract. 

A  conversion  to  EPOS  was  not  carried  out 
until  one  year  later  (1989).  Thus,  the  main 
reguireaents  to  be  aet  by  the  veapon  systea  had 
not  yet  been  specified  for  the  first  Functional 
Reguireaent  Docuaents  (FRDs) ,.  such  as  Avionic 
Systea  FRD  and  Subsystoa  FRD.*,  in  a  Reguireaent 
Data  Base.  It  was  not  until  preparation  of  later 
versions  of  these  FRDs,  that  the  Reguireaent  Data 
Base  could  be  assessed. 

Vhether  or  not  system  developaent  could  have 
been  carried  out  that  rapidly  and  saoothly  given 
early  availability  of  the  transformer,  so  that  one 
really  could  speak  of  a  top-down  design,  cannot  be 
deterained  by  this  briefer.  In  this  connection, 
the  top-down  design  means  to  aake  the  following 
approach: 

*  At  first,  preparation  of  the  System  FRDs 
for  the  avionic,,  flight  control  and  utility 
control  systems  on  the  basis  of  the  Veapon 
System  Design  and  Performance  Specification 
(!•'  level) 

*  subseguently,  preparation  of  the  Subsystea 
FRDs  (2“  level) 

a  based  on  that,,  preparation  of  the  LRI 
Processing/Sof tvare  Reguireaent  Specifica¬ 
tions  and  of  the  eguipaent  specifications 
(laa  level). 

Above  all,  the  determination  as  to  which 
reguireaent/task  is  to  be  aet  or  carried  out  by 
hardware,  and  which  one  by  software,,  will  be 
decided  not  before  the  2*"  systea  design  level. 

I  consider  the  late  availability  of  parts 
of  the  systea  design  tools  CORE/EPOS  (that  is, 
including  the  transformer,  the  "problem  child"  of 
that  tool  coabination)  as  the  aain  reason  tha' 
departure  froa  this  ideal  top-down  design. 

Parallel  to  the  preparation  of  the  design 
docuaents  (Avionic  Systea  FRD  and  Subsystea  FRDs), 
that  IS,  before  systea  design  of  th"  2“  level 


(Subsystea  FRDs)  had  been  completed,  the  eguipaent 
specifications  were  established.  Otherwise  -  as 
stated  by  Eurofighter  Co.  -  the  fixed  target  dates 
of  the  developaent  prograaae  -  particularly  the 
first  flight  of  the  first  prototype  (POD  and/or 
that  of  the  first  avionic  prototype  (P05)  -  could 
not  be  aet. 

At  an  Design  Review,  held  in  January  1989, 
the  Avionic  Joint  Teaa  explained  in  detail  how  the 
basic  docuaents  (ESR,  VSDPS)  and  the  design 
documents  (FRDs,  LRI  Processing  Specifications) 
should  serve  to  carry  out  system  design  and 
developaent  of  both  hardware  and  software  by  means 
of 

*  a  aarket  survey  (based  on  ESR) 

w  preliBinary  eguipaent  design  reguireaents 
(based  on  logistic  reguireaents  of  the 
VSDPS  and  "initial  unit  functions"  of  the 
Systea  FRDs) 

*  tender  specifications  (among  other  things 
based  on  the  detailed  functions  of  the 
Subsystea  FRDs) 

w  contract  specifications. 

The  customer  (NEFHA/Nations)  is  not 
enthusiastic  about  this  course  of  action  since  it 
represents  "rather  an  eiiuipBent  specification  loop 
than  an  eqaipaent  specification  route",  and  since 
the  proposals  may  have  a  strong  impact  on  the 
systea/subsystea  design. 

5.  "LESSOg  LEARWr 

Vhen  considering  all  tools,  one  thing  becoaes 
very  clear:  the  design  tool  is  most  critical.  All 
other  tools  are  needed  later  on  in  the  project 
life  cycle;  that  is,  there  is  usually  sufficient 
time  for  their 

*  selection 

*  procurement,  and 

*  any  adaptation  dovelopaents,  if  reguired. 

Especially  in  the  case  of  systea  design 
tools,  their  absolutely  necessary  use  may  be 
easily  put  at  risk  as  iaportant  developaent  steps 
are  initially  taken  without  then,  thus  making 
early  decisions,  which  could  be  corrected,  not  at 
all  or  only  with  great  difficulty  (and  usually 
turning  out  to  be  also  very  costly).  To  aake  it 
clear,  use  of  tools  will  not  prevent  design 
errors.  But  if  the  designer  is  using  such  tools, 
his  attention  is  in  aany  cases  called  early  enough 
to  inconsistencies  and  other  deficiencies  in  his 
design  that  correction  will  be  possible  without 
too  great  difficulties  (and  usually  also  not  great 
cost) . 

The  experiences  gained  froa  the  EFA  Project 
to  date,  clearly  show  that 

*  international  (NATO)  standards  for  systea- 
and  software  development,  including  docu- 
aentation  and  tools,  as  well  as 

*  early  decisions  on  the  design  tools  to  be 
used  (that  is,  already  at  the  start  of 
multinational  cooperation;  however,  not 
only  between  the  nations,  but  also  between 
the  participating  industrial  companies) 

are  urgently  reguired. 

Moreover,  a  top-down  design  as  described 
earlier  would  certainly  be  desirable.  This, 
however,  may  be  possible  only  if  -  at  the  time  of 
signing  the  main  developaent  contract 

*  the  aarket  survey  has  been  completed 


*  the  system  design  has  been  completed,,  if 
possible  down  to  the  LRI  Processing 
Specification  level,,  but  at  least  to  the 
Subsystem  FRD  level,  and 

*  the  tender  specifications  have  been 
prepared  for  all.  eguipments/subsystems/ 
systems. 

This,  however,,  will  not  be  realizable  since 
the  basis  of  system  design  -  that  is,  the 
technical  specification  (in  our  case,  the  VSDPS)  ' 
IS  usually  agreed  in  a  binding  manner  together 
with  the  main  development  contract. 

This  dilemma  could  probably  be  evaded  only  if 
development  is  carried  out  in  stages,  that  is 

*  at  first,  system  design  until  the  above 
preconditions  have  been  net,  and 

*  then  development  with  the  invitation  to 
tender  for  the  eguipments,  is  not  started 
before  the  second  stage. 

However,  I  cannot  really  say  whether  such  a 
course  of  action  would  actually  be  possible  and. 
If  so,  whether  it  would  also  help  to  resolve  the 
problems  described. 
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SUMMARY 

The  two  most  widely  used  standards 
covering  the  development  of  software  in 
the  military  and  civil  avionics 
industries  are  DOD-STD-2167A  and  RTCA 
D0.178A/EUR0CAE  ED-12A  respectively. 
This  latter  document  is  currently 
undergoing  extensive  update  by  RTCA 
Special  Committee  167  and  EUROCAE 
Working  Group  12,  with  a  planned 
document  re-issue  date  of  the  end  of 
1991.  This  paper  compares  D0D-STD-2167A 
with  the  work  currently  being  undertaken 
by  SC.167/WG.12. 

1.  IHTRODUCTIOW 

As  a  direct  consequence  of  the  size  of 
the  US  defence  market,  the  most  commonly 
used  standard  covering  the  development 
of  military  guidance  and  control 
software  is  DOD-STD-2167A,  'Military 
Standard,  Defence  System  Software 
Development',  (Ref.  1). 

RTCA  DO-178A/EUROCAE  ED-12A,  'Software 
Considerations  in  Airborne  Systems  and 
Equipment  Certification',  (Ref.  9),  has 
been  used  by  the  world's  civil  aviation 
certification  authorities  as  the  basis 
for  clearing  avionic  equipment  and 
systems  containing  software,  since  1985. 
It  should  be  noted  that  software  is  only 
certificated  as  an  integral  part  of 
equipment  or  a  system,  never  stand 
alone.  The  document  is  currently 
undergoing  an  extensive  revision  by  RTCA 
Special  Committee  167  and  EUROCAE 
Working  Group  12 .  The  current  target 
date  for  the  publication  of  DO-178B/ED- 
12B  is  December  1991. 

This  paper  compares  the  requirements 
contained  in  DOD-STD-2167A  with  the 
discussions  taking  place  within  SC- 
167/WG  12.  It  must  be  emphasised  that 
the  revised  DO-178A/ED-12A  guidelines, 
discussed  in  the  text,  are  based  on  the 
author's  understandi.ng  of  the  status  of 
the  activities  within  SC-167/WG  12  as  at 
the  end  of  January  1991. 

Note:  The  terms  SC-167  and  00-1783  are 

used  subsequently  in  the  text  to 
reflect  the  activities  jointly 
being  undertaken  by  SC-167  and  WG 
12,  and  the  current  working 
position  of  the  revision  to  DO- 
178A/ED-12A,  respectively. 

UK  DEF  STAN  00-55,  'Requirements  for  the 
Procurement  of  Safety  Critical  Software 
in  Defence  Equipment',  was  issued  in  May 
1989  as  a  draft  interim  standard.  A 
number  of  its  requirements,  including 
mandatory  use  of  formal  mathematical 
methods,  and  use  of  an  organisationally 
independent  verification  and  validation 
teeun,  gave  rise  to  strong  reaction  from 


UK  industry.  As  a  consequence  of  the 
large  number  of  comma  .-.Is  received,  Che 
document  has  been  undergoing,  what  is 
believed  to  be,  significant 
modification.  It  had  been  intended  that 
this  paper  would  compare  the  contents  of 
the  revised  standard  with  the 
requirements  of  DOD-STD-2167A  and  DO- 
178B.  However,  at  the  time  of  writing, 
the  revised  document  has  not  been 
released,  the  comparison  has  therefore 
not  been  possible. 

2.  HISTORY 

DOD-STD-2167 

DOD-STD-2167  was  initially  released  in 
June  1985  with  the  aim  of  reducing  the 
occurrence  of  programme  cost  and 
schedule  overruns  and  at  improving  the 
quality  and  maintainability  of  software 
products . 

Revision  A  of  the  standard  was  released 
in  February  1988  in  order  to  take 
account  of  the  comments  and  criticisms 
received  following  the  practical 
application  of  the  requirements 
specified  in  the  original  document.  In 
particular,  the  new  Issue  addresses  the 
identified  deficiencies  with  respect  to 
incompatibilities  with  the  use  of  Ada 
and  with  new  and  evolving  software 
engineering  technologies. 

RTCA  DO-178 

RTCA  DO-178  was  first  published  in 
January  1982  following  agreement, 
between  the  certification  authorities 
and  industry,  on  the  need  for  guidelines 
covering  the  certification  of  avionic 
equipment  containing  digital  computers. 
The  document  was  specifically  aimed  at 
providing  guidance  on  hew  the 
authorities'  requirements,  particularly 
with  respect  to  safety,  might  be 
satisfied. 

In  1983  it  was  decided  that  the  document 
should  be  revised  to  reflect  the 
experience  gained  during  the  initial 
period  of  field  application.  Revision  A 
of  the  document  was  published  in  March 
1985. 

Following  the  circulation  of  a 
questionnaire  by  the  FAA  to  industry, 
reguesting  information  on  the  experience 
gained  and  problems  identified  with 
using  DO-178A,  RTCA  established  SC-167 
in  October  1989.  SC-167  was  tasked 
updating  the  document  with  the  aim  of 
making  software  production  more 
effective  and  efficient,  and  at  the  same 
time,  enable  a  more  consistent 
interpretation. 
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A  copy  of  the  Terms  of  Reference  for  SC- 
167  are  included  as  Appendix  1. 

3.  PORPOSg  AND  SCOPS 
DOD-STD-2167A 

The  main  purpose  of  the  document  is  to 
provide  a  procurement  specification  for 
deliverable  software  in  the  form  of 
Computer  Software  Configuration  Items 
(CSCI's) .  However,  the  requirements  may 
also  be  applied  to  the  development  of 
software  delivered  as  part  of  Hardware 
Configuration  Items,  firmware  and  non¬ 
deliverable  software. 

The  document  defines  the  software 
development  process  as  shown  in  Figure 
1 .  The  fact  that  the  process  begins  and 
ends  with  system  related  activities, 
emphasises  the  importance  of  the  need  to 
control  the  interface  between  the  system 
and  software  development  activities. 

DOD-STD-2167A,  in  addition  to  the 
specific  requirements  it  contains,  calls 
up  five  further  standards  covering 
configuration  control,  specification 
practices,  management  and  technical 
reviews  and  audits. 

RTCA  DO-178B 

The  purpose  of  the  document  is  to 
identify  and  describe  software 
development  and  management  methods  and 
techniques,  whose  application  will 
result  in  software  products  which 
perform  their  intended  function  in 
compliance  with  airworthiness  safety 
requirements . 

The  guidelines  are  intended  Cor  use  in 
either  the  development,  modification  or 
approval  of  systems  and  equipment .  They 
may  also  be  used  for  the  qualification 
of  software  tools  and  methodologies, 
used  in  the  certification  process.  The 
guidelines  are  not  intended  to  be 
applied  to  user  selectable  databases  or 
to  support  software  which  is  not  safety 
related. 

The  document  only  provides  guidance  on 
software  considerations,  it  is  not 
within  the  scope  of  DO-178B  to  provide 
guidance  on  systems  processes.  The 
document  only  refers  to  items  of 
information  which  are  expected  to  be 
transmitted  between  the  system  and 
software  processes. 

4.  MAMAGEMENT  OF  THE  SOFTWARZ 
DEVELOPMENT  PROglgg 

DOD-STD-2167A 

The  equipment  supplier  is  required  to 
establish  a  project  software  development 
life-cycle  consisting  of  the  activities 
identified  in  Figure  1.  The  activities 
are  permitted  to  overlap  and  be 
performed  iteratively  or  re-cursively . 

Details  of  how  the  identified  activities 
are  to  be  performed  and  how  they  relate 
to  the  formal  reviews  and  audits, 
required  by  the  contract,  are  documented 
in  the  pro3ect  Software  Development  Plan 


(SDP)  .  With  the  exception  of  scheduling 
data,  all  updates  to  the  SDP  require 
customer  approval.  Any  specific  aspects 
of  the  proposed  development  programme 
which  are  considered  to  be  a  potential 
source  of  technical,  cost  or  schedule 
risk,  must  be  identified,  analyzed, 
prioritised  and  monitored. 

The  potential  need  for  subcontractor 
management,  establishing  an  interface  to 
an  Independent  Verification  and 
Validation  body  and  security  are  also 
identified. 

The  supplier  is  required  to  monitor  the 
utilisation  of  processing  resources 
throughout  the  programme  and  to  re¬ 
allocate  resources  as  reguired  in  order 
to  meet  the  reserve  requirements. 

If  use  of  a  High  Order  Language  is  not 
mandated  in  the  contract,  the  choice  of 
language  to  be  used  is  subject  to 
approval  by  the  customer. 

The  need  to  plan  the  transfer  of  the 
product  from  a  development  to  a  support 
environment  is  identified  together  with 
the  associated  requirements  for 
maintenance  and  documentation  specific 
to  the  support  activity. 

RTCA  DO-178B 

The  primary  purpose  of  the  guidance 
material  which  will  be  provided  in 
relation  to  the  management  process,  is 
aimed  at  providing  the  certification 
authorities  with  confidence  that  the 
software  products  meet  their 
requirements  with  respect  to  safety. 

The  software  development  process  model 
likely  to  be  adopted  by  the  document 
will  be  based  on  a  subset  of  the 
proposals  made  by  the  IEEE,  (Ref  2)  . 
This  defines  the  software  lifecycle  as  a 
sequence  of  processes,  see  Figure  2. 
Each  process  includes  a  number  of 
activities  which  must  be  completed  in 
order  to  complete  the  lifecycle, 
however,  activities  need  not  be 
completed  in  a  single  'pass'  through  the 
process . 

The  appropriate  software  lifecycle  is 
determined  for  each  software  development 
task.  Large  developments  could  be 
broken  down  into  separate  tasks,  each 
having  a  distinct  lifecycle. 

A  software  lifecycle  is  made  up  of 
software  development  and  integral 
processes.  Development  processes  are 
product  orientated  activities,  i.e. 
planning,  requirements  analysis,  design, 
code  and  integration.  Integral 
processes  provide  engineering  support 
and  assurance  functions  such  as 
verification,  configuration  management, 
quality  assurance,  etc.  These  latter 
processes  are  required  to  ensure  the 
completion  of  the  lifecycle  and  the 
quality  of  the  end  product. 

The  planning  process  is  fundamental  to 
the  development  of  good  quality 
software,  it  is  during  this  phase  that 
the  specific  lifecycle  (s)  for  the 
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project  is  (are)  defined.  This  planning 
activity  only  relates  to  software 
development  and  is  subset  of  overall 
project  management. 

Hota;  Business  or  commercially  related 
programme  management  activities 
are  currently  being  addressed  by 
thp  ARINC/AEEC  Software 
Management  Sub-Committee  which  is 
developing  Project  Paper  652 
'Guidance  for  Avionics  Software 
Management' . 

5.  SYSTEM  DEFINITION 

DOD-STD-2167A 

The  standard  divides  the  System 
Definition  phase  into  two  separate 
activities.  System  Requirements 
Analysis/  which  involves  a  review  of  the 
(customer)  system  specification  to 
remove  any  deficiencies  eg  ambiguities, 
omissions,  inconsistencies,  etc.,  and 
System  Design,  where  the  requirements 
are  allocated  between  hardware,  software 
and  the  'user'  .  This  latter  activity 
results  in  the  system  being  partitioned 
in  to  hardware  and  software 
configuration  items,  and,  where 
appropriate,  manual  operations. 

In  order  to  minimise  the  chances  of  the 
system  entering  a  hazardous  state  during 
operation,  the  supplier  is  required  to 
po'form  a  safety  analysis.  Any 
potentially  hazardous  events  must  be 
clearly  identified  and  documented. 

As  part  of  this  phase  the  supplier  is 
required  to  develop  preliminary  software 
and  interface  requirements  for  each 
CSCI. 

The  output  of  the  System  Definition 
process  provides  a  ' functional  baseline' 
on  which  the  software  requirements  will 
be  based. 

RTCA  DO-178B 

As  stated  in  section  3,  systems  related 
activities  are  outside  the  scope  of  DO- 
178B,  SC-167  is  only  addressing  those 

items  of  information  which  pass  between 
the  systems  and  software  processes. 

Mote;  SAE,  at  the  request  of  the  FAA, 
has  established  a  group  tas)ced 
with  developing  system 
integration  requirements.  This 
group  is  wor)iinq  closely  with  SC- 
167  to  establish  an  interface 
between  the  two  activities. 

The  purpose  of  the  system/software 
interface  is  to  identify  the  input 
requirements,  necessary  to  enable  the 
software  development  process  to  proceed, 
and  the  outputs  of  the  process,  needed 
for  use  in  system  validation.  One  of 
the  major  issues  being  addressed  is  the 
traceability  and  accountability  to  those 
system  requirements  which  are  related  to 
system  safety.  The  aim  being  to 
establish  safety  directed  software 
development  process.  Figure  3  contains 
an  overview  of  the  flow  of  information 
between  system  safety  related  processes 


and  the  currently  proposed  software 
development  processes . 

System  safety  requirements  may  be 
satisfied  in  two  ways,  namely,  preclude 
by  design  or  prove  absence  through 
verification.  All  safety  requirements 
allocated  to  software  will  be  documented 
in  the  software  requirements.  The 
requirements  will  also  specify  the 
software  criticality  level. 

SC-167  has  currently  identified  five 
levels  of  software  criticality,  A 
through  E.  The  levels  are  tied  to  the 
failure  condition  categories  as  defined 
in  AMJ  25-1309  i.e.  Catastrophic, 
Severe/Major  (Hazardous),  Major  and 
Minor,  plus  a  category  corresponding  to 
the  case  where  there  are  no  safety 
implications.  The  selection  of  software 
level  will  be  based  on  the  potential 
contribution  of  software  to  a  failure 
condition,  as  determined  by  a  system 
safety  assessment  activity.  Appendix  2 
contains  definitions  of  the  failure 
condition  categories  and  the 
corresponding  software  levels. 

6.  SOFTWARE  REQUIREMEMTS  ANALYSIS 

DOD-STD-2167A 

The  purpose  of  this  phase  is  identified 
as  an  analysis  of  the  system 
requirements  allocated  to  each  CSCI  and 
the  definition  of  a  complete  sot  of 
software  and  interface  requirements. 
Included  in  the  analysis  are  the 
processing  resource  and  reserve 
requirements  for  each  configuration  item 
including  throughput,  memory  and  I/O 
port  loading. 

The  resultant  CSCI  software  and 
interface  requirements  form  the 
'allocated  baseline'  for  the  software 
design  process. 

RTCA  DO-178B 

The  inputs  to  this  activity  are 
identified  as  system  requirements 
allocated  to  software,  specific  safety 
related  requirements,  software 
criticality  level,  project  standards  and 
the  approved  project  approaches  to 
software  development,  quality  assurance 
and  configuration  management. 
Subsequent  to  the  initial  pass  through 
the  process,  inputs  will  ta)^e  the  form 
of  requirement  changes  and  feedbac)r  from 
later  processes. 

The  activities  associated  with  this 
process  are  aimed  at  generating  a  well 
defined  and  traceable  set  of  software 
requirements  for  use  by  subsequent 
processes.  Any  deficiencies  identified 
during  this  process  must  be  fed  back 
into  the  system  process . 

The  only  impact  of  software  criticality 
level  on  this  process  is  li)^ely  to  be  in 
the  level  of  detail  provided  by  the 
documentation. 
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7.  SOFTWARE  DESIGN 
DOD-STD-2167A 

The  standard  separates  this  activity 
into  Preliminary  and  Detailed  Design. 
The  process  involves  the  partitioning  of 
each  CSCI  into  Computer  Software 
Components  (CSC's)  and  Computer  Software 
Units  (CSU's).  An  example  of  a 
'typical'  decomposition  of  a  CSCI  is 
shown  in  Figure  4. 

The  preliminary  design  activity  results 
in  the  definition  of  the  high  level 
design  of  each  CSCI  and  allocates 
software  and  interface  requirements  to 
CSC's.  This  activity  also  involves  the 
preliminary  design  of  the  interfaces 
external  to  the  CSCI. 

The  detailed  design  activity  involves 
the  breakdown  of  the  high  level  design 
to  unit  level,  by  allocating  software 
requirements  from  the  CSC' a  to  the 
CSU's.  The  detailed  design  of  the 
interfaces  external  to  the  CSCI  is  also 
developed  during  this  phase. 

There  is  a  requirement  to  consider  the 
use  of  Non-Developmental  Software  (NDS) 
ie  re-usable  software,  commercial  off- 
the-shelf  (COTS)  software,  and 
Government  furnished  software,  during 
the  software  design  process.  Any  use  of 
NDS  software  must  be  agreed  by  the 
customer,  identified  in  the  project 
plans  and  documented  in  accordance  with 
the  requirements  of  che  standard. 

In  order  to  assist  the  future 
understanding  of  botli  the  high  level  and 
detailed  design,  supporting  information, 
such  as  rationale,  results  of  analyses 
and  trade-off  studies,  etc,,  must  be 
retained  and  documented. 

RTCA  DO-178B 

The  design  process  is  divided  into  two 
parts,  high-level  architecture 
definition  and  detailed  software  design. 
The  architecture  definition  activity 
involves  the  allocation  of  requirements 
to  high  level  software  functions,  plus 
the  definition  and  design  of  the 
hardware/software  and  software/software 
interfaces.  The  detailed  design  process 
includes  definition  of  the  low-level 
structure  of  the  software  tasks  and  che 
allocation  of  requirements  to  software 
units. 

The  inputs  to  the  process,  in  addition 
to  the  software  and  interface 
requirements,  include  design  standards 
and  the  approved  project  approach  to 
tools,  verification,  configuration 
management  and  quality  assurance. 
Following  the  initial  pass,  inputs  also 
arise  as  a  result  of  requirement  changes 
and  feedback  from  subsequent  processes. 

The  document  will  also  address  the  use 
of  software  developed  as  part  of  another 
project  i.e.  re-used  software,  and 
software  supplied  by  a  third  party  e.g. 
Ada  run-time  libraries  and  COTS 
software.  Consiceration  will  be  given 
tc  the  consequential  impact  on  the 


design  process  of  including  software  not 
necessarily  developed  to  the  same 
standards  and  procedures. 

Guidelines  are  also  being  developed  to 
cover  special  design  requirements  for 
developing  'User  Modifiable'  software. 
This  is  defined  as  software  which  may  be 
modified,  within  fixet  constraints,  by 
the  end  user,  without  any  requirement 
for  re-certification.  The  limits, 
within  which,  the  user  is  permitted  to 
change  the  software,  are  identified  and 
approved  by  the  certification 
authorities,  at  the  time  the  equipment 
is  cleared  to  enter  service. 

The  process  product  is  a  design 
description,  including  traceability  back 
to  the  software  requirements.  The  only 
impact  of  software  criticality  level  on 
this  process  is  likely  to  be  in  the 
level  of  detail  provided  by  the 
documentation  generated., 

8.  SOFTWARE  IMPLEMENTATION 
DOD-STD-2167A 

The  standard  specifies  language 
independent  coding  standards  and  the 
supplier  is  responsible  for  developing 
project  specific  codes  of  practice  in 
accordance  with  these  requirements. 
Following  acceptance  by  the  customer, 
the  standards  are  employed  in  the 
implementation  of  the  requirements  of 
each  CSU. 

RTCA.  D0-17BB 

The  coding  process  involves  the 
production  of  source  code  based  on  the 
software  design  and  requirements.  It 
will  be  generated  in  accordance  with 
project  coding  standards  and  subject  to 
the  approved  quality  assurance  and 
configuration  management  procedures. 

Any  deficiencies  identified  in  the 
requirements  handed  down  must  be  fed 
back  to  the  preceding  processes  for 
correction  or  clarification. 

9.  SOFTWARE  VERIFICATION 
DOD-ST'D-2167A 

The  verification  requirements  contained 
within  the  standard  are  distributed  over 
a  number  of  activities  and  involve 
reviews,  product  evaluations, 
development  testing  and  formal 
qualification  testing.  An  important 
aspect  of  the  verification  process  is 
the  need  to  provide  documented 
traceability  of  the  system  requirements 
allocated  to  each  CSCI,  its  CSC's  and 
CSU's  and  to  formal  test  cases. 

The  supplier  is  required  to  conduct  or 
support  formal  reviews  at  various  stages 
of  the  project  as  indicated  in  Figure  1. 
All  technical  reviews  are  required  to  be 
performed  in  accordance  with  MIL-STD- 
1521  (Ref.  8).  The  standard  does  allow 
sufficient  flexibility  to  enable  reviews 
to  be  planned  and  scheduled  to  meet 
project  needs,  multiple  reviews  (e.g. 
PDR' s  and  CDR's)  are  also  permitted. 
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Evaluations  are  required  to  be  performed 
on  all  deliverable  software  and 
documents  at  specified  stages  in  the 
development  lire-cjfcle.  In  order  to 
ensure  adequate  objectivity,  personnel 
involved  in  the  development  of  a 
product,  may  not  conduct  its  evaluation, 
but,  members  of  the  engineering  team  are 
permitted  to  participate  in  the 
activity.  All  records  associated  with 
evaluations,  including  problem 
identification  and  corrective  action, 
must  be  retained  and  available  for 
review  by  the  customer.  Details  of 
default  evaluation  criteria  are  provided 
by  the  standard,  but  the  supplier  is 
free  to  propose  alternate  or  additional 
criteria,  subject  to  customer  approval. 

The  supplier  is  required  to  perform 
development  testing  on  all  CSU's  and 
integration  testing  on  all  CSC's  to 
ensure  that  they  satisfy  their 
specifications.  In  both  cases  the  test 
procedures  and  results  must  be  recorded 
and  retained. 

Following  completion  of  the  integration 
testing  activity,  the  process  by  which 
the  CSU's  and  CSC's  are  combined  to  form 
an  Integrated  software  product  i.e.  a 
CSCI,  the  product  together  with  its 
associated  formal  test  documentation,  is 
reviewed  to  determine  its  readiness  for 
Formal  Qualification  Testing  <FQT) . 

The  supplier  is  required  to  develop  and 
document  plans  and  procedures  for 
performing  FQT  in  a  Software  Test  Plan 
(STP) .  Following  its  acceptance  by  the 
customer^  with  the  exception  of 
scheduling  Information,  all  changes  to 
the  STP  must  be  subject  to  customer 
approval . 

The  STP  is  required  to  contain  details 
of  the  software  development  environment 
to  be  used,  including  information 
relating  to  its  verification, 
configuration  management  and 
maintenance.  Further,  in  order  to 
ensure  the  required  degree  of 
objectivity,  persons  involved  in  the 
development  of  the  software,  may  not 
conduct  the  FQT,  however,  members  of  the 
engineering  team  may  participate  in  the 
activity.  The  STP  will  contain  details 
of  how  the  stipulated  level  of 
Independence  is  to  be  achieved. 

FQT  activities  related  to  each  step  in 
the  software  development  life  cycle, 
shown  in  Figure  1,  are  identified  within 
the  standard. 

When  the  CSCI  testing  activity  has  been 
completed,  the  software  product  must  be 
integrated  into  the  system  and  the 
system  validated  agaii.st  the 
requirements  identified  and  documented 
during  the  system  requirement  analysis 
phase . 

Functional  and  Physical  Configuration 
Audits  must  be  performed  on  each  CSCI  on 
completion  of  either  the  CSCI,  or  system 
integration  activities.  The  product  of 
this  activity  provides  the  'product 
baseline'  for  all  subsequent  activities. 


On  completion,  all  documentation 
associated  with  the  FQT  and  audit 
activities  is  required  to  be  reviewed 
prior  to  delivery  to  the  customer. 

RTa\  DO-176 

The  document  will  identify  verification 
as  an  integral  process  and  as  such, 
verification  related  activities  are 
carried  out  as  part  of,  or  in  parallel 
with,  the  development  processes  ••  The 
guidelines  will  divide  the  verification 
process  into  two  principle  activities  ie 
reviews  and  analyses,  and  testing. 
Emphasis  will  be  on  the  importance  of 
reviews  during  the  recpiirements 
analysis,  design  and  coding  processes 
and  on  testing  during  the  integration 
process.  The  need  to  perform  analyses 
during  all  phases  of  the  life-cycle  will 
also  be  emphasised. 

Reviews  and  analyses  are  required  to 
ensure  the  correct  and  complete 
translation  of,  system  requirements  to 
software  requirements,  software 
requirements  to  design  and  eventually  to 
code.  At  each  stage,  any  requirements 
related  to  safety  must  be  identified  and 
addressed  specifically.  The  review 
activity  must  include  checks  to  assure 
adherence  to  the  appropriate  project 
standards,  whilst  the  analyses  verify 
compliance  with,  and  traceability,  to 
higher  level  requirements. 

The  guidelines  will  identify  the  fact 
that  since  the  design  process  make  take 
the  form  of  a  number  of  iterative  steps 
the  verification  activity  itself  may 
also  be  iterative. 

The  results  of  the  verification 
activities  must  be  recorded  and 
retained,  details  of  problems 
identified,  logged  and  corrective  action 
tracked.  Traceability  is  also  required 
from  system  requirements  to  the 
verification  products.  In  some  cases, 
particularly  where  the  software  is 
classified  as  safety  critical,  a  review 
of  the  verification  products  may  be 
required,  in  order  to  provide  assurance 
of  the  completeness  i.e. 
comprehensiveness,  of  each  verification 
activity. 

Testing  is  identified  as  providing 
evidence  that  a  function  has  been 
implemented  correctly,  and  as  a  means  of 
identifying  interface  definition 
deficiencies.  The  benefits  oi 
addressing  the  specific  needs  of  the 
testing  activity  during  the  requirements 
analysis  and  design  phases  will  be 
identified,  as  will  the  need  to  test  for 
both  normal  and  error  conditions. 

The  document  will  identify  three 
categories  of  testing  ie  low-level, 
software  integration  and 
hardware/software  integration.  It  will 
also  emphasise  that  the  majority  of  the 
test  procedures  should  be  developed  110.1 
the  software  requirements.  There  will 
be  a  requirement  to  carry  out  a 
structural  coverage  analysis  on  the 
requ.’  rement  based  test  procedures  ana 
source  code,  to  demonstrate  that  the 
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11.  SOFTWARE  QUALITY  ASSURANCE 
DOD-STD-2167A 


code  structure  has  been  adequately 
exercised.  This  latter  activity  may 
identify  the  need  for  additional  test 
cases . 

The  guidelines  will  identify  that  the 
depth  and  scope  of  the  verification 
rocess  is  governed  by  the  criticality 
evel  of  the  software.  The  document 
will  provide  guidelines  on  the  minimum 
verification  retjuirements  for  each 
software  criticality  level. 

In  order  to  ensure  that  the  right  level 
of  objectivity  in  the  various 
verification  activities,  the 
verification  of  the  individual  products 
of  the  software  development  process, 
must  be  performed  by  someone  other  than 
the  person (3)  who  developed  the  product. 

10.  SOFTWARE  COWFIGURATIOW  HAKXGEMEKT 

DO-3TD-2167A 

The  supplier  is  required  to  establish 
and  maintain  a  software  development 
library  together  with  the  necessary 
supporting  plans  and  procedures.  The 
latter  are  required  to  enable  the 
software  and  related  documentation 
produced  durino  the  development  process, 
to  be  identified  and  controlled.  All 
problems  identified  with  software  and/or 
documentation  placed  under  configuration 
control,  or  with  the  development  life- 
cycle  processes,  are  required  to  be 
subject  to  a  corrective  action 
procedure.  This  process  will  include  an 
analysis  to  detect  any  adverse  trends  in 
the  problems  identified. 

Minimum  requirements  with  respect  to 
configuration  identification,  control 
and  status  accounting  are  provided, 
together  with  category  and  priority 
classifications  for  problem  reporting. 
The  standard  also  calls  up  DOD-STD's  480 
and  481  (Refs.  6  and  7  respectively). 

The  specific  configuration  management 
requirements  related  to  each  step  of  the 
software  development  life  cycle,  shown 
in  Figure  1,  are  identified  within  the 
standard. 

RTCA  PO-178B 

To  date,  SC-167  has  not  reached  any  firm 
conclusions  with  respect  to  guidelines 
for  software  configuration  management. 

It  has  been  agreed  that  there  is  a  need 
for  a  disciplined  configuration 
management  approach  throughout  the 
software  product  life-cycle.  It  is 
considered  important  that  identifiable 
configuration  items  and  baselines  are 
established  to  enable  the  software  to  be 
controlled,  documented,  verified, 
maintained,  reviewed  and  audited. 

It  is  also  accepted  that  there  is  a 
requirement  for  a  formal  change  control 
procedure  to  be  in  place  which  includes 
a  method  of  recording  problems  and 
tracking  their  resolution. 


The  standard  does  not  address  the 
requirements  for  quality  assurance 
explicitly,  however,  the  need  for 
independence  in  carrying  out  the 
evaluation  and  testing  activities  can  be 
classified  as  a  quality  assurance 
requirement.  Also,  a  number  of  the 
default  product  evaluation  criteria, 
identified  in  the  docirrent,  can  be 
considered  to  be  quality  assurance 
related. 

Military  project  software  quality 
assurance  requirements  are  provided  by 
other  documents  such  as  DOD-STD-2168  and 
AQAP  13  (Refs.  4  and  5  respectively) . 

RTCA  DO-178B 

SC-167  has  yet  to  reach  any  firm 
conclusions  on  guidelines  for  software 
quality  assurance. 

The  objectives  of  software  quality 
assurance  process  have  been  identified 
as: 

(a)  to  assure  that  plans,  standards  and 
procedures  are  established  and  'fit 
for  purpose' , 

(b)  to  assure  that  approved  plans, 
standards  and  procedures  are  being 
complied  with, 

(c)  to  assure  that  the  evidence  eg 
records,  etc,,  provide  confidence 
that  the  software  products  conform 
to  the  established  technical, 
procedural  and  safety  requirements, 

(d)  to  ensure  that  the  entire 
development  life-cycle  process  is 
reviewed  and  any  deficiencies 
identified  and  corrected. 

The  above  will  be  achieved  by  closely 
monitoring  and  auditing  the  project 
activities,  whilst  maintaining  the 
independence  of  the  quality  assurance 
function. 

12.  DOCOMEWTATION 
DOD-Sro-2167A 

The  content  and  format  of  each 
deliverable  document  is  defined  in  a 
Data  Item  Description,  (DID) ,  which  is 
considered  to  form  part  of  the  standard. 
A  list  of  the  deliverable  documents  is 
provided  in  Figure  5. 

The  standard  requires  more  documentation 
to  be  made  available  for  review  or  audit 
than  is  identified  as  deliverable.  The 
project  specific  deliverable 
documentation  requirements  are  provided 
in  the  Contract  Data  Requirement  List 
(CDRL) .  The  SDP  must  include  the 
justification  for  not  producing  non¬ 
deliverable  documentation  identified  in 
the  standard.  The  format  and  content  of 
all  non-deliverable  documentation  to  be 
generated  must  also  be  specified  in  the 
SPD. 
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Each  document  DID  provides  very  detailed 
information  on  layout,  sub-paragraph 
content,  the  applicable  sections  of 
relevant  standards,  and  at  which 
review (s)  the  document  should  be 
presented  for  approval. 

In  order  to  minimise  unnecessary 
overheads  MIL-HDBK-287,  (Ref.  3),  has 
been  produced  to  assist  projects  to 
'tailor'  the  documentation  generated  to 
their  specific  needs .  Tailoring  may  be 
used  to  eliminate  either  non -applicable 
sections  of  individual  documents  or 
complete  documents.  Project  specific 
instructions  for  tailoring  DOD-STD-2167A 
requirements  will  normally  be  specified 
in  the  Statement  of  Work  (SOW) ,  whilst 
tailoring  instructions  for  the  DID's 
will  be  specified  in  the  CDRL.  The 
extent  to  which  project  specific 
tailoring  has  occurred  must  be 
identified  in  the  SDP. 

RTCA  DO-178B 

The  document  will  identify  the 
information  which  will  be  required  to 
support  system/equipment  certification. 
The  information  needed  can  be 
categorised  as  follows: 

(a)  Process  Definitions 

These  will  take  the  form  of  plans 
and  standards  which  will  detail  the 
strategies  to  be  followed  and  the 
methods  and  tools  to  be  employed. 
Information  relating  to  the 
configuration  of  the 
support/development  environment 
will  also  be  required. 

(b)  Process  Outputs 

These  may  take  the  form  of 
requirements  and  design 
documentation,  source  code,  and 
verification  procedures  and 
results.  The  information  supplied 
will  provide  the  evidence  required 
to  prove  that  an  activity  has  been 
completed  satisfactorily,  in 
compliance  with  its  plans  and 
standards.  Also,  to  enable  the 
software  products  to  be  controlled 
and  maintained,  configuration 
Index's  must  be  produced. 

(c)  Summary  Information 

Both  the  certification  plan  and  the 
accomplishment  summary  are  used  to 
optimise  the  certification  process. 

DO-178B  will  only  provide  guidelines  on 
the  information  to  be  supplied.  Apart 
from  grouping  the  information  under 
headings  eg  Software  Quality  Assurance 
Plan,  Software  Requirements,  etc.,  no 
specific  requirements  with  respect  to 
format  and  structure  will  be  provided. 
The  information  may  be  made  available  in 
a  number  of  forms  such  as  individual 
documents,  combined  into  larger 
documents,  distributed  across  several 
documents,  or  on  magnetic  media.  The 
only  requirements  are  that  it  must  be 
available  in  form  which  can  be  reviewed 
efficiently,  and  that  the  mechanism 
chosen  must  be  identified  in  the 
Certification  Plan. 


13.  CERTIFICATION 
D0D-STD-2167A 

The  standard  has  been  developed  to 
establish  a  common  interface  between 
customers,  suppliers  and  maintainers. 
As  such,  it  is  not  intended  to  be  used 
directly,  to  provide  a  third  party,  such 
as  the  civil  aviation  certification 
authorities,  with  the  level  of 
visibility  they  require.  The  document 
therefore  does  not  contain  any  specific 
requirements  related  to  this  activity. 

RTCA  DO-178B 

The  primary  purpose  of  the  guidelines  is 
to  enable  the  supplier  to  provide  the 
certification  authorities  with  proof 
that  the  software  content  of  the  system 
or  equipment  has  been  developed  in  a 
structured  manner.  This  proof  may 
involve  an  audit  of  the  development 
process  employed,  a  review  of  the 
project  documentation,  concurrence  with 
the  suppliers  statement  of  compliance, 
Or  some  combination  of  all  three. 

The  level  of  involvement  by  the 
certification  authorities  will  be 
dependent  on  the  system  safety 
assessment  and  the  resultant  criticality 
level  given  to  the  software  functions. 
The  level  of  rigor  to  be  applied, 
particularly  in  relation  to  the 
verification  process,  and  the  amount  of 
data  required  as  deliverables,  will  be 
dependent  on  the  potential  impact  of  any 
software  errors  on  the  safety  of  the 
aircraft. 

Based  on  knowledge  of  the  software 
level  (s),  the  supplier  is  required  to 
develop  plans  covering  certification, 
quality  assurance,  configuration 
management  and  verification.  These 
plans  will  be  used  to  inform  the 
certification  authorities  of  the 
methods,  tools  and  techniques  which  will 
be  used  to  design,  implement,  verify  and 
control  the  software  development 
process.  The  plans  should  be  prepared 
in  advance  of  the  software  development 
life-cycle  activities. 

As  a  minimum,  the  certification 
authorities  will  require  delivery  of  the 
following  plans.  Software  Aspects  of 
Certification,  Software  Quality 
Assurance  and  Software  Configuration 
Management,  together  with  a  Software 
Accomplishment  Summary.  Additional 
documentation  deliveries  will  depend  on 
the  criticality  of  the  software.  The 
supplier  will  be  required  to  propose  a 
set  of  deliverables  as  part  of  the 
Certification  Plan. 

Any  documentation  submitted  as  evidence 
of  compliance  must  be  that  which 
controls,  or  results  from,  the  software 
development  process,  with  the  exception 
of  the  Accomplishment  Summary,  no 
document  should  be  produced  solely  for 
use  by  the  authorities. 

If  a  supplier  wishes  to  reduce  or 
eliminate  particular  verification 
activities  by  using  a  software  tool,  the 
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certification  authorities  will  require 
the  tool  to  be  'qualified' .  Guidelines 
will  be  provided  for  determining  if 
software  tool  qualification  should  be 
sought  and,  if  so,  the  process  to  be 
followed  in  order  to  obtain 
certification  authority  approval. 

14.  CONCLUSIOKS 

DOD-STD-2167A  was  developed  principally 
as  a  procurement  standard  and  as  such, 
it  provides  detailed  requirements  with 
respect  to  the  software  development 
documentation  required  as  deliverables. 
It  also  identifies  deliverable  documents 
which  are  specific  to  the  needs  of  users 
and  software  support  personnel. 
Although  there  is  a  requirement  to  carry 
out  a  safety  analysis  to  identify  any 
safety  related  risks,  no  specific  hazard 
classification  related  variation  in 
requirements  is  identified.  Variation 
may  be  possible  by  means  of  the 
tailoring  information  contained  in  MIL- 
HDBK-287. 

The  guidelines  provided  by  RTCA  DO-178B 
are  primarily  aimed  at  giving  the 
certification  authorities  the  assurance 
that  the  software  has  been  developed  in 
accordance  with  the  regulations, 
particularly  those  related  to  safety.  A 
great  deal  of  emphasis  will  therefore  be 
placed  on  the  verification,  assurance 
and  control  related  activities. 
Information  will  also  be  provided  on  how 
the  requirements  may  be  modified  for  the 
different  software  criticality  levels. 

It  should  be  emphasised  that  the  civil 
certification  authorities  do  not 
certificate  software  stand-alone, 
software  will  only  be  certificated  as  an 
integral  part  of  equipment  or  a  system. 
DOD-STD-2167A  does  cover  the  situation 
where  the  procured  item  is  a  software 
product  ie  a  CSCI . 

Provided  the  additional  documents 
required  by  RTCA  DO-178B  are  available 
eg  Accomplishment  Summary,  Quality 
Assurance  Plan,  etc.,  and  the  supplier 
call  amonstrate  that  the  contents  of  the 
documents,  produced  in  accordance  with 
DOD-STD-2167A,  comply  with  the  RTCA  DO- 
178B  guidelines,  then  it  should  be 
possible  to  obtain  certification 
authority  approval  for  a  CSCI  as  part  of 
a  system  or  piece  of  equipment. 

However,  due  to  the  deqree  of  document 
format  and  content  flaxibility  likely  to 
be  available  within  the  guidelines  of 
RTCA  DO-178B,  the  probability  of  it 
being  acceptable  for  a  procurement 
against  the  requirements  of  DOD-STD- 
2167A  is  not  high. 

As  stated  previously  the  comments  on  the 
likely  contents  of  DO-178B  are  based  on 
the  author's  understanding  of  the  status 
of  the  discussion  at  the  end  of  January 
1991.  The  content  and  structure  of  the 
document  may  change  significantly  by  the 
time  it  is  finally  issued. 
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APPENDIX  1 
TZSMS  or  REFERENCE 
Spacial  Coomittee  167 
DZGIXAL  AVIONICS  SOFZMARE 


Special  Committee  167  shall  review  and 
revise,  as  necessary,  RTCA  Document  DO- 
178A,  "Software  Considerations  in 
Airborne  Systems  and  Equipment 
Certification" . 


GOIDANCE: 

In  accomplishing  its  work  the  Special 
Committee  should  recognise  the  dynamic, 
evolving  environment  for  software 
requirements,  software  design, 
generation,  testing  and  documentation, 
and  formulate  a  revised  document  that 
can  accommodate  this  environment  while 
recommending  suitably  rigorous 
technicpies.  To  accomplish  this 

revision,  the  Special  Committee  should 
consider  the  experience  gained  through 
the  field  application  of  the  guidance 
material  contained  in  DO-178,  and  DO- 
178A,  as  well  as  the  results  of  recent 
research  in  software  engineering.  SC167 
should  also  recognise  the  International 
implications  of  this  document  and, 
therefore,  should  establish  a  close 
working  relationship  with  EUROCAE  (which 
has  become  the  normal  practice  in  RTCA 
Committees) .  An  objective  should  be  to 
achieve  a  common/parallel  RTCA/EOR(X:ae 
document.  The  Special  Committee  should 
focus  this  review  to  address  the 
following  areas: 

1.  Examine  existing  Industry  and 

fovernraent  standards  and  consider 
or  possible  adaptation  or 
reference,  where  relevant. 

2.  Assess  the  adequacy  of  existing 

software  levels  and  the  associated 
nature  and  degree  of  analysis, 
verification,  test  and  assurance 
activities.  The  revised  process 
criteria  should  be  structured  to 
support  objective  compliance 
demonstration, 

3.  Examine  the  criteria  for  tools  to 

be  used  for  certification  credit 
(e.g.  development,  configuration 
management  and  verification  tools) . 

4.  Examine  the  certification  criteria 

for  reusable  software,  off-the- 
shelf  software,  databases,  and 
user-modifiable  software  for  the 
system  to  be  certified. 

5.  Excimine  the  certification  criteria 

for  architectural  and 
methodological  approaches  used  to 
reduce  the  software  level  or  to 
provide  verification  coverage  (e.g. 
partitioning  and  dissimilar 
software) . 

6.  Examine  configuration  control 

guidelines,  quality  assurance 

guidelines,  and  identification 
conventions,  and  their 
compatibility  with  existing 
regulatory  requirements  for  type 
certification,  in-service 
modificatio.is,  and  equipment 


approval. 

7.  Consider  the  impact  of  new 
technology  such  as  modular 
architecture,  data  loading, 
packaging  and  memory  technology. 

8.  Examine  the  need,  content,  and 
delivery  requirements  of  all 
documents,  with  special  emphasis  on 
the  accomplishment  summary. 

9.  Define  and  consider  the  interfaces 
between  the  software  and  systems 
development  life  cycles. 

10.  Review  the  criteria  associated  with 
making  pre-  and  post-certification 
changes  to  a  system. 

11.  Consider  the  impact  of  evolutionary 
development  and  other  alternative 
life  cycles  to  the  model  in^lied  by 
DO-178A. 
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APPENDIX  2 
RTCA  DO-178B  (DRAFT) 


SYSTEM  CRITICALITY  CATEGORY  AND  SOFTWARE 
LEVEL  FAILURE  CONDITION  CATEGORIES 

The  failure  condition  categories 
described  below  are  those  accepted  by 
the  aviation  community  and  the 
certification  authorities  for  use  in 
equipment  and  system  certification.  The 
categories  are  based  upon  the  severity 
of  the  effects  of  failures  or  design 
errors  on  the  aircraft,  crew,  and 
occupants.  The  categories  are: 

a.  Catastrophic  -  Failure  conditions 
which  would  prevent  continued  safe 
flight  and  landing. 


b.  Hazardous /Severe -Mai or  -  Failure 
conditions  which  would  reduce  the 
capability  of  the  aircraft  or  the 
ability  of  the  crew  to  cope  with 
adverse  operating  conditions  to  the 
extent  that  there  would  be: 

*  a  large  reduction  in  safety 
margins  or  functional 
capabilities . 

*  physical  stress  or  higher 
workload  such  that  the  flight 
crew  could  not  be  relied  on  to 
perform  their  tasks  accurately  or 
completely;  or 

*  serious  or  fatal  injury  to  a 
relatively  small  number  of  the 
occupants . 

c.  Major  -  Failure  conditions  which 
would  reduce  the  capability  of  the 
aircraft  or  the  ability  of  the  crew 
to  cope  with  adverse  operating 
conditions  to  the  extent  that  there 
would  be,  for  exa^le,  a 
significant  reduction  in  safety 
margins  or  functional  capabilities, 
a  significant  increase  in  crew 
workload  or  rn  conditions  impairing 
crew  efficiency,  or  some  discomfort 
to  occupants. 

d.  Minor  -  Failure  conditions  which 
would  not  significantly  reduce 
aircraft  safety,  and  which  involve 
crew  actions  that  are  well  within 
their  capabilities..  Minor  failure 
conditions  may  include,  for 
example,  a  slight  increase  in  crew 
workload,  such  as  routine  flight 
plan  changes,  or  some  inconvenience 
to  occupants. 

e.  No  Effect  -  Failure  conditions 
which  do  not  effect  the  operational 
capability  of  the  aircraft  or 
increase  pilot  workload. 


SOFTWARE  LEVELS 

a.  Level  A  -  Software  who  anomalous 

behaviour,  as  shown  by  a  system 
safety  assessment,  would  lead  to  a 
failure  of  system  function 

resulting  in  a  catastrophic  failure 
condition  for  the  aircraft. 

b.  Level  B  -  Software  whose  anomalous 

behaviour,  as  shown  by  a  system 
safety  assessment,  would  lead  to  a 
failure  of  system  function 

resulting  in  a  hazardous/severe- 

major  failure  condition  for  the 
aircraft . 

c.  Level  C  -  Software  whose  anomalous 

behaviour,  as  shown  by  a  system 
safety  assessment,  would  lead  to  a 
failure  system  function  resulting 

in  a  major  failure  condition  for 
the  aircraft. 

d.  Level  D  -  Software  whose  anomalous 
behaviour,  as  shown  by  a  system 
safety  assessment,  would  lead  to  a 
failure  of  system  function 
resulting  in  a  minor  failure 
condition  for  the  aircraft. 

Level  E  -  Software  whose  anomalous 
behaviour,  as  shown  by  a  system 
safety  assessment,  would  lead  to  a 
failure  of  system  function  with  no 
consequences  for  the  aircraft. 
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FIG,1  SOFTWARE  DEVELOPMENT  PROCESS  DOD-STD-21 67A 


FIG. 2  SOFTWARE  LIFE  CYCLE  PROCESS  MODEL  RTCA  DO-178B  (DRAFT) 
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Fin. 3  SYSTEM  SAFETY  PROCESS  INTERACTION  WITH  SOFTWARE  PROCESSES 
RTCA  DO-178B  (DRAFT) 
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DOCUMENT  REFERENCE  NUMBER 


PLANS 

Soltware  Development  Plan  (SDP) 

Software  Test  Plan  (STP) 

SOFTWARE  DEVELOPMENT  DOCUMENTATION 
Syslem/Segmeni  Specification  (SSS) 
Syslem'Segment  Design  Document  (SSDD) 
Interface  Requirement  Specification  (IRS) 
Software  Requirement  Specification  (SRS) 
Software  Design  Document  (SDD) 

Interface  Design  Document  (lOD) 

Software  Test  Description  (STD) 

Software  Test  Report  (STR) 

Software  Product  Specification  (SPS) 
CONFIGURATION  CONTROL 

Version  Description  Document  (VDD) 
Engineering  Change  Proposal  (ECP) 
Specification  Change  Notice  (SCN) 
SUPPORT 

Computer  System  Operators  Manual  (CSOM) 
Software  Users  Manual  (SUM) 

Software  Programmers  Manual  (SPM) 
Firmcare  Support  Manual  (FSM) 

Computer  Resources  Interface  Support 
Document  (CRISD) 


DI-MCCR-80030A 

DI-MCCR-80014A 

DI.CMAN-80008A 

DI-CMAN-80534 

DI-MCCR-80026A 

DI-MCCR-80025A 

DI-MCCR-80012A 

DI-MCCR-80027A 

DI-MCCR-80015A 

DI-MCCR-80017A 

DI-MCCR-80029A 

DI-MCCR-80013A 

DI-CMAN-80639 

DI-CMAN-80642 

DI-MCCR-80018A 

DI-MCCR-80019A 

DI-MCCR-80021A 

DI-MCCR-80022A 

DI-MCCR-80024A 


FIG. 5  DELIVERABLE  DOCUMENTS  DOD-STD-2167A 


PLANS 

Software  Aspects  of  Cortilication  Plan 
Software  Quality  Assuiance  Plan 
Software  Configuration  Management  Plan 
Soltware  Verilication  Plan 
SOFTWARE  DEVELOPMENT 

System  Requirements  Document 
Soltware  Requirements  Document 
Software  Design  Description  Document 
Source  Code 

Software  Verification  Procedures  and  Results  Document 
CONFIGURATION  MANAGEMENT 

Unit  Configuration  Identification  Document 
System  (Configuration  tdentilication  Document 
SUPPORT 

Support/Oevetopment  System  Configuration  Document 
STANDARDS 

Software  Design  Standards 
CERTIFICATION 

Accomplishment  Summary 


FIG. 6  SOFTWARE  DEVELOPMENT  DOCUMENTS  RTCA  DO-178  B  (DRAFT) 
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REQUIREMENTS  AND  TRACEABILITY  MANAGEMENT 

Author:  G  M  Cross,  Marconi  Underwater  Systems  Limited 
Station  Road.  WeybrkJge,  SURREY.  KT15  2PW.  ENGUND 


ABSTRACT 

This  paper  explains  the  contribution  of  requirements 
traceability  to  the  system  development  process  in  risk 
reduction  and  rework  avoidance  and  the  impact  on  all 
phases  of  project  development  from  requirements 
capture  through  to  customer  acceptance  and 
subsequent  maintenance.  By  update  of  the  traditional 
lifecycle  model,  the  paper  shows  how  the  RTM^ 
(Requirements  and  Traceability  Management)  product 
builds  a  system  development  environment  addressing 
these  issues  and  improving  the  benefits  to  Users  of  many 
of  todays  leading  CASE  tools  by  more  effective 
Integration,  with  a  total  lifecycle  coverage. 

Introduction  and  background  to  tha  work 

Traditionally,  the  processes  Involved  in  System 
Development  have  relied  heavily  upon  decisions  m^e  on 
the  basis  of  experience  and  intuition.  In  particular,  these 
decisions  are  predominantly  made  in  the  earliest,  most 
critical  phases  of  the  project,  where  any  errors  have 
maximum  cost  impact.  Furthermore,  these  critical 
decisions  are  often  made  arbitrarily  and  are  rarely 
recorded  in  a  formal  manner.  The  traditional  system 
development  process  therefore  lacks  traceability.  The 
result  of  such  an  approach  is  a  system  which  cannot 
easily  be  shown  to  meet  the  customer  requirements. 

As  part  ol  the  investment  by  Marconi  Underwater 
Systems  Limited  (MUSL)  into  producing  high  quality 
systems  and  software,  MUSL  have  performed  a  careful 
analysis  of  the  activities  to  be  supported  during  the 
systems  development  lifecycle.  Research  started 
several  years  ago,  when  It  became  apparent  to  MUSL  as 
an  early  adopter  of  CASE  that  some  of  these  tools  had 
serious  deficiencies  and  were  difficult  to  manage 
effectively  over  multiple  projects.  For  example,  poor 
integration  meant  excessive  Engineer  interaction  to 
produce  consolidatad  documentation,  leading  in  turn  to 
low  maintainability  as  source  data  changed,  in  particular, 
the  issues  of  technical  control  and  management  of 
traceability  and  configuration  were  poorly  addressed,  and 
lifecycle  support  was  incomplete  and  fragmented. 

In  order  to  better  understand  these  problems,  MUSL 
produced  a  system  development  process  model  (SOPM) 
using  the  Yourdon  method.  This  model  considers  system 
development  as  a  series  ol  transforming  processes 
operating  on  the  customer's  requirements,  to  produce 
different  representations  of  the  system  under 
development  and  resulting  in  the  finished  product  offered 
for  acceptance.  An  important  result  from  the  model  is  that 
management  of  the  customer  requirement,  its  detailed 
analysis  and  understanding,  and  traceability  through  to 
acceptance  are  key  lifecycle  activities. 

Requirements  Traceability 

In  the  classic  V-Oiagram  (Figure  1)  we  have 
historically  underated  the  role  of  traceability  in 
establishing  early  lifecycle  verification  as  the  design 
evolves. 


MUive  a  nMwe 


As  we  move  out  of  the  bottom  of  the  V  from  code 
production  we  are  all  too  often  merely  testing  that  the 
coded  and  integrated  system  accurately  reproduces  the 
errors  lying  undetected  in  the  products  of  the  preceding 
analysis  and  design  phases.  Then  eventually,  as  we 
come  to  acceptance  and  we  measure  the  system  against 
the  input  requirement,  the  painful  truth  is  finally  revealedi 
It  is  a  'standard  result*^  that  almost  two  thirds  of  defects 
detected  at  integration  and  acceptance  result  from  latent 
analysis  errors. 

Clearly  what  Is  needed  Is  to  establish  a  much  earlier 
confidence  in  the  quality  ol  the  requirement,  followed  by 
traceability  into  the  analysis  phase  and  beyond,  and  a 
comparison  between  the  products  of  each  phase  to 
check  for  consistency.  Traceability  is  'good  common 
sense',  and  most  technical  managers  will  basically 
recognise  that  they  use  this  approach  informally  In 
attempting  to  manage  the  risk  in  their  projects,  lor 
example,  as  part  of  their  design  review  activities  It  is 
also  required  by  standard  DOD-STD-21 67A  However,  the 
full  benefit  can  only  be  realised  by  rigorous  application, 
and  this  demands  effective  tool  support. 

Traceability  Toolset  requirements 

The  results  of  the  MUSL  SDPM  work  also  suggested 
that  a  standard  model  for  traceability  was  impossible  to 
agree,  and  that  one  ought  to  allow  tailoring  of  the  process 
model  to  optimise  it  for  a  given  project.  This  in  turn  needs 
to  be  reflected  by  flexible  configuration  of  the  toolset. 

In  order  to  get  the  best  return  from  traceability  we 
need  to  examine  the  total  system  development  process, 
as  MUSL  did  with  the  SDPM,  and  then  fabricate  an  IPSE 
where  traceability  is  the  underlying  strategy  tor  tool  data 
integration.  We  thus  identify  the  bridges  which  need  to  be 
built  between  the  co-operating  CASE  tools  in  order  to 
provide  design  traceability  throughout  the  lifecycle.  All  of 
this  has  to  be  achieved  of  course,  in  the  environment  of  a 
dynamically  changing  system  requirement  as  the  project 
proceeds.  A  successful  implementation  must  provide 
facilities  for; 

•  Total  lifecycle  support  'Cradle  to  Grave* 

•  Initial  requirement  specification  capture  and 
subsequent  configuration  management 

•  Clarifying  and  refining  poorly  specified  customer 
requirement  statements 
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•  Updating  of  Customer  originated  specificatbns, 
preserving  Customer's  format  for  meaningful 
dialogue 

•  Dynamic  traceability,  linking  to  all  lifecycle  phase 
products,  and  linking  phase  to  phase 

•  Configurable  traceability  map  to  reflect  local  project 
needs 

•  Partitioning  and  managing  designs,  thus  enabling 
sub-contractors  to  demonstrate  compliancy  at  every 
phase 

•  Generation  of  compliancy  reports  supporting 
verification  eg  to  DOD-STD-2167A 

•  Acceptance  specification  production  facilities  for 
system  validation 

•  Audit  trails  of  design  history  to  support  design  review 
and  maintenance 

•  Impact  analysis  for  change  management 

These  were  some  of  the  objectives  of  MUSL's  RTM, 
and  the  rest  of  the  paper  explains  the  relevance  and 
benefit  of  these  objectives  in  an  effective,  high 
productivity  total  Systems  Development  Environment 
(SDE).  The  motivation  behind  the  production  of  this 
environment  and  underlying  method  Is  to  maximise 
support  in  the  early  phases  of  design  for  the  scarce 
system  designer  resource,  and  to  encourage  rational  and 
explicit  decision-making  by  provision  of  a  consistent  set 
of  guidelines  for  decision-making  and  recording  of  those 
decisions. 

Component*  of  an  RTM  based  SDE 

At  the  heart  of  RTM  Is  the  Project  Database.  This 
database  holds  information  pertaining  to  all  phases  of  the 
project,  but  focuses  primarily  upon  the  system 
requirements  and  the  tracking  of  these  through  the 
project  development  cycle. 


Fig  2.  RTM  based  System  Development  Environment 
This  type  of  database  is  often  referred  to  as  a  Verification 
Cross-Reference  Index  (VCRI),  and  is  used  to  audit  the 
compliancy  of  the  project  to  the  User  requirement  through 
the  successive  phases  of  development,  culminating  in 


Customer  acceptance.  Figure  2  shows  the  basic 
elements  of  a  System  Development  Environment 
constructed  around  RTM,  in  the  context  of  the  software 
development  tasks  on  a  project.  An  upgradable 
architecture  of  UNIX  workstations  forms  the  platform  for 
the  tools. 

Requirements  Capture 

In  real  world  situations  the  requirements  to  be 
captured  by  RTM  will  come  from  various  sources.  Most 
commonly  they  will  be  presented  as  a  Customer  supplied 
document,  or  they  may  be  presented  as  requirements 
assembled  from  a  number  of  different  documents.  Under 
some  circumstances  they  may  be  a  set  of  derived 
requirements  resulting  from  the  reverse  engineering  of  an 
existing  system.  The  first  step  in  the  RTM  process  is  to 
capture  this  information  electronically.  Those  items  which 
are  not  supplied  by  the  Customer  in  an  electronic  form 
can  be  captured  by  scanning  the  Customer  supplied 
document  or  if  necessary  typed  directly  into  RTM  afresh. 
Once  this  information  Is  electronically  captured  the  full 
facilities  of  RTM  can  be  applied.  To  maintain  and  ensure 
the  integrity  of  the  original  captured  requirements  they 
are  made  avaiiable  to  the  RTM  toolset  in  read-only  mode. 

Requirement*  Stripping 

All  documents  which  contain  requirements  relating  to 
the  proposed  system  are  systematically  transferred  into 
the  Project  Database  In  a  process  known  as  requirement 
stripping.  Typical  examples  of  these  documents  would  be 
documents  defining  the  contractual  standards,  and 
documents  defining  system  specific  requirements.  As 
each  requirement  statement  Is  extracted  from  these 
documents  and  Inserted  Into  the  database,  the  document 
identity  and  paragraph  number  from  which  it  was 
extracted  is  recorded  In  the  database.  Any  newly  derived 
requirements  which  result  from  points  of  clarification  or 
the  like  are  documented  and  approved  before  being 
added  to  the  project  database  as  configuration  items. 
After  subsequent  clarification  and  refinement  as 
described  below,  it  is  then  possible  to  reconstruct  all  of 
the  original  documents  automatically  to  allow  customer 
approval  of  the  updates  as  valid  interpretations  of  their 
needs.  A  browse  facility  in  RTM  enables  users  to  scan 
the  original  requirements  document  either  on  a  line  by  line 
basis  or  by  using  ’string  searches’.  The  desired 
requirements  text  is  interactively  identified  and 
transferred  to  a  database,  accompanied  by  a  record  of 
which  section  of  the  customer  document  it  was  extracted 
from. 

Requirement*  Engineering 

Once  all  the  requirements  have  been  extracted  from 
the  Customer's  source  documents  it  is  necessary  to 
examine  and  engineer  them  so  that  any  ambiguities 
errors  or  duplicates  are  identified  and  addressed. 
Normally  this  activity  would  be  performed  by  a  small 
group  of  subject  matter  experts  who  are  able  to 
communicate  directly  with  one  another.  The  aim  is  to 
inject  as  much  subject  matter  knowiedge  as  possible  into 
the  requirements  at  the  earliest  stage,  so  that 
requirements  are  well  defined  before  requirements 
subsets  are  passed  on  to  the  analysis  teams.  The 
analysis  teams  are  then  able  lo  concentrate  mainly  on 
grouping  and  partitioning  the  requirements  in  a  logical 
manner,  using  the  specific  subject  matter  knowledge 
which  has  already  been  injected.  RTM  provides  facilities 
to  enable  the  following  requirements  engineering 
functions  lo  be  performed  whilst  at  all  times  maintaining 
the  necessary  links  to  provide  an  audit  trail  back  to  the 
functional  requirements  as  stated  by  the  customer: 
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One  to  One  Substltutlcri  This  is  basically  a  simple 
edit  of  the  requirement. 

One  to  Many  Subatltutlon  Allows  a  complex 
requirement  to  be  broken  down  into  iis  component 
parts  thereby  generating  "child"  requirements. 

Many  to  One  Substitution  Allows  duplicate  or 
similar  requirements  to  be  focused  down  into  a  single 
requirements  statement. 

Clarification  of  Requirements  Allows  additional 
notes  to  be  added  (Engineers  note  pad)  and 
associated  with  the  requirement  for  use  by  analysts 
or  designers  later  in  the  project's  lifecycle.  These 
notes  are  not  normally  produced  or  included  in  any 
automated  reporting  to  the  customer.  The  notes  do 
not  affect  the  text  of  the  requirement. 

Requirements  Questions  Provides  for  questions 
on  specific  requirements  to  bo  raised  and  fed  back  to 
the  customer  (points  of  clarification)  with  the 
updated  specification. 

It  is  not  uncommon  that  a  customer  statement  of 
functional  requirements,  for  a  medium  sized  system  will 
generate  many  thousands  of  engineering  requirements,  h 
is  easier  and  more  efficient  to  manage  large  volumes  of 
requirements  if  they  are  broken  down  into  categorised 
subsets.  Within  RTM  this  is  achieved  by  classifying  the 
requirements  by  keywords: 

Daflnltlon  of  Keywords  Any  cnaracter  string  can 
be  delined  as  a  keyword.  Keywords  can  be  linked  to 
requirements  either  manually  or  by  automatically 
searching  through  the  requirements  for  the  keyword 
character  string.  For  example  use  of  the  string 
"Engineer*  would  result  in  all  requirements  where  that 
string  appears  in  the  text  being  identified  and  linked 


to  the  keyword.  Also  a  pseudonym  text  string  can  be 
used.  In  this  case  the  requirements  are  searched  for 
the  pseudonym  text  string  and  those  requirements 
linked  to  the  keyword. 

Keyword  Reports  Having  grouped  requirements 
together  under  keywords,  reports  can  automatically 
be  generated  identifying  which  requirements  are 
associated  with  what  keyword. 

Keyword  Viewpoints  Keywords  can  also  be 
grouped  together  in  sophisticated  hierarchies 
allowing  the  selection  and  identification  of 
requirements  by  a  related  group  of  keywords.  This 
can  be  used  as  initial  partitioning  of  the  requirements 
as  we  move  into  the  analysis  phase. 

Lifecycle  Traceability 

Having  captured,  understood  and  engineered  the 
requirements,  it  is  important  to  ensure  that  each 
requirement  is  correctly  designed  for  and  implemented, 
and  that  the  impact  of  any  future  changes  in  the 
requirements  is  fully  understood  and  traceable. 

A  high  level  view  of  the  System  Design  Process 
model  is  shown  at  Fig  3  in  a  wateilall  layout.  It  shows  how 
RTM  relates  to  the  major  project  phases  and  how  the 
major  inputs  to  each  phase  are  the  outputs  of  the 
previous  one.  The  outputs  of  each  phase  are  baselines  of 
the  evolving  design  of  the  product,  together  with  the 
design  compliancy  data  against  the  requirements.  From 
the  figure  it  can  be  seen  that  RTM  supports  traceability 
through  the  entire  project  lifecycle  from  the  initial  capture 
of  customer  requirements  through  to  delivery  of  the 
accepted  systems  and  subsequent  maintenance 
support. 
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Fig  3.  RTM  project  Lifecycle 
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With  traceability  links  in  place  to  all  the  products  of 
design,  it  is  then  possible  to  see  the  impact  of  a  specific 
requirements  change  down  through  analysis,  design, 
implementation  and  testing. 

The  project  phases  are  supported  by  the  following  tools: 


Requirements 

Analysis 

Design 

Coding 

CM 


RIM 

Teamwork  or  StP 
Teamwork  or  StP 
User  Specified 
PCMS 


Documentation  Framemaker  or  Interleaf 


Analysts  and  Design 

As  we  move  into  structured  analysis  and  design 
(SASD)  using  for  instance  Yourdon,  we  first  build  an 
essential  model  which  is  equivalent  to  a  Functional 
Baseline.  This  is  a  secure  basis  for  progressing  to  the 
stage  of  allocating  functions  to  hardware  and  software 
architectures  in  the  implementation  model.  To  provide 
traceability  links  to  any  elements  of  SASD  models, 
integration  modules  are  provided  for  industry  standard 
SASD  tools.  Note  that  the  analysis  phase  will  typically 
cause  some  update  to  requirements,  and  with  RTM,  these 
can  now  be  kept  in  track. 

Because  each  object  in  the  model  is  tied  to  the 
requirements  it  can  be  demonstrated  that  there  is  nothing 
superfluous  or  missing  and  full  compliance  can  be  readily 
demonstrated  by  a  simple  report  from  the  Project 
Database. 

In  the  design  phase  we  are  concerned  with  reviewing 
candidate  solution$,to  arrive  at  an  optimum  approach 
before  producing  the  coded  system.  The  candidate 
solutions  are  represented  as  'distortions’  of  the  essential 
modal.  Distortion  in  this  context  means  that  extra 
functions  may  neeo  to  be  added  to  establish 
communication  between  items  of  'off-the-shelf* 
equipment  or  software.  Another  example  would  be  where 
an  essential  function  is  split  between  two  processors  for 
reasons  of  cost,  performance,  space  or  customer 
constraint.  These  constraints  can  be  tied  into  the  system 
design  using  RTM.  Allocation  of  objects  in  the  essential 
model  can  be  mapped  on  to  the  implementation  model 
objects  to  assure  consistency  ol  the  two  models. 

Tasting  and  Acceptance 

A  number  of  trials  specifications  are  produced 
directly  from  the  requirements  in  the  database.  These  will 
detail  the  tests  necessary  to  demonstrate  to  the 
satisfaction  of  the  customer  that  a  set  of  requirements 
ha.i'  been  fulfilled. 

■*.n  acceptance  test  plan  and  record  is  drawn  up 
which  shows  the  manner  in  which  the  trials  are  conducted 
and  records  the  outcome  of  those  trials.  Requirements 
are  marked  as  having  been  accepted  upon  successful 
completion  of  their  associated  trial.  A  full  audit  of  where 
the  project  is  proving  the  implementation  of  requirements 
is  available  from  the  VCRI  (Verification  and  Cross 
Referencing  Index)  report. 

Traceability  Schema  Configuration 

RTM  provides  facilities  which  allow  entities  and 
relationships  to  be  defined  to  suit  the  particular 
requirements  of  a  project  and  to  be  stored  in  the 
database.  An  example  of  such  a  schema  to  support  a 
project  is  shown  Figure  4. 


The  user  can  define  any  object  type  which  is  required 
to  support  the  project's  lifecycle,  lor  example.  Event 
Lists,  Essential  Model  Objects,  Implementational  Model 
Objects,  Test  specifications,  etc.  In  addition  the  user 
can  define  any  links  (relationships)  between  the  object 
types.  These  relationships  can  then  be  associated  with  a 
requirement.  Where  supported  by  the  systems  analysis 
and  design  tool  in  use,  these  objects  and  relationships 
can  be  described  graphically  by  creating  an  entity 
relationship  diagram  from  which  information  is  captured 
and  automatically  entered  into  the  controlling  database. 

Traceability  to  non  Integrated  tools 

Certain  development  tasks  will  be  performed  with 
tools  which  may  not  be  integrated  fully  with  RTM,  tor 
example  reliability  modelling.  In  such  cases,  the 
appropriate  requirements  are  selected  from  the  Oracle 
database  using  keyword  classification.  The  teams 
responsible  for  addressing  those  requirements  rrake 
compliancy  statements  against  each  of  the  selected 
requirements,  indicating  for  each  concept  which 
requirements  are  fuKillsd.  In  this  way,  full  traceability  is 
assured. 

Impact  Analysis 

RTM  provides  standard  reporting  features  which  will 
identify  objects  which  are  linked  to  requirements, 
requirements  which  are  linked  to  oojects,  and  objects 
which  are  linked  to  other  objects.  These  reports  enable 
the  impact  of  requests  for  changes  to  original 
requirements  to  be  comprehensively  analysed  and 
assessed. 

Compliancy  Reporting  and  Audit 

RTM  also  provides  standard  reports  which  will 
identify  requirements  not  supported  by  analysis  or 
implementational  objects,  which  thus  indicate 
deficiencies  in  the  analysis  or  of  the  implementation 
design.  Conversely  reports  can  also  be  generated  which 
will  show  analysis  or  implementation  objects  which  do  not 
support  a  specilic  requireme.it,  which  may  indicate  over 
design  or  the  provision  of  functionality  not  requested  by 
the  customer.  This  also  documents  design  decisions 
taken  by  engineers  ensuring  that  project  continuity  is 
maintained  even  with  staff  turnover. 

Automated  Documentation 

The  ability  to  automatically  generate  meaningful, 
quality  documentation  in  support  of  the  requirements 
capture,  design  and  impfementation  phases  of  the 
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lifecycle  is  very  important.  It  improves  project 
communication  and  enhances  reporting  and 
communication  between  the  customer  and  project.  When 
all  the  captured  requirement  have  been  engineered  as 
described  above,  a  complete  report  can  be  presented  to 
the  customer.  This  report  wili  coniain  lire  customer's 
requirements  mapped  to  the  resultant  engineered 
requirements,  to  any  questions  (points  of  clarification)  as 
described  above,  and  to  the  evolving  design  that 
satisfies  the  engineered  requirements.  These  reports  are 
fully  automated,  so  that  latest  document  versions  can  be 
produced  with  high  productivity. 


CONCLUSIONS 

The  Benefits  of  Requirements  and  Traceability 
Management 

Throughout  the  project  development  lifecycle,  the 
database  will  provide  accurate  and  concise  information 
relating  to  many  aspects  of  the  project; 

•  Risk  Management.  Resolving  the  ambiguities  in 
the  requirement  specification  as  part  of  a  meaningful 
dialogue  with  the  customer,  minimises  the  risk  to 
both  parties.  Subsequently,  through  life  traceability 
ensures  we  build  the  system  we  have  contracted  to 
build,  and  plan  acceptance  at  the  earliest  stage 
possible. 

•  Project  Management.  It  is  possible  to  obtain  an 
instant  statement  of  the  degree  of  compliancy  in 
terms  of  those  requirements  which  have  been 
engineered,  analysed,  designed,  implemented, 
tested  and  accepted.  This  provides  the  project 
manager  with  an  objective  indicator  of  the  progress 
of  the  project. 

<  Raquiramant  Change  Control.  When  a 
requirement  changes,  h  is  possible  immediately  to 
determine  which  project  tasks  are  affected  either 
directly  or  indirectly,  and  how  many  hardware  and 
software  modules  may  have  to  be  modified. 

•  Testing.  When  producing  a  test  specification  for  a 
particular  module,  the  Protect  Database  will  provide  a 
list  of  all  the  requirements  which  the  module  should 
fulfil.  The  test  can  then  be  conducted  on  the  basis  of 
these  requirements,  and  does  not  merely  confirm 
that  design  errors  have  been  faithfully  reproduced  by 
the  implementationi 

•  Intsgratlon/Accsptance  If  during  trials  a 
requirement  does  not  appear  to  have  been 
implemented  correctly,  the  Project  Database  will 
identify  the  module  or  modules  which  purport  to 
implement  the  requirement  in  question,  along  with  the 
analysis  and  design  objects  from  which  they  were 
derived.  This  greatly  reduces  the  extent  and  cost  of 
the  investigation  which  needs  to  be  performed. 

•  Documentation.  Because  the  majority  of  the 
system  development  tasks  are  performed  using 
software  tools,  it  is  possible  to  automate  the 
generation  of  high  quality,  consistent  documentatior' 
to  specified  standards  at  the  appropriate  time. 

•  Maintenance.  Several  of  the  traditional  difficulties 
encountered  during  maintenance  are  reduced  due  to 
the  recording  of  traceability  data  in  the  project 
database.  This  reduces  reliance  on  project  experts, 
and  allows  areas  likely  to  be  affected  by  proposed 
changes  to  be  more  easily  identified. 


References 

1.  RTM  (Requirements  and  Traceability  Management)  is  a 
CASE  tool  developed  by  GEC-Marconi  &  MAIT  Limited, 
and  distributed  in  Europe  by  SQL  Systems  International 
of  Harlow,  Essex,  England. 

2.  B.  Boehm,  IEEE  Trans  Software  Eng.  March  1975, 
PI  25. 


5-1 


COPROCESSOR  SUPPORT  FOR  REAL-TIME  ADA 
by 

R.  K.  Page 

Senior  Software  Technologist 
Naval  Weapons  Center 
Code  3922 

China  Lake,  CA  93555-6001 
USA 


SUMMARY 

The  purpose  of  this  paper  is  to  propose  the  basic 
elements  of  a  real-time  clock  that  would  be  suitable 
for  use  with  the  tasking  mechanism  of  the  Ada 
programming  language  and  other  real-time 
concurrency  management  systems.  A  real-time 
application  needs  such  a  clock  for  several  reasons: 

1 .  To  relieve  the  processor  of  some  of  the 
overhead  burden  of  time  and  task  management. 

2.  To  provide  adequate  granularity  for  the 
reprc.sentation  of  time. 

3.  To  provide  .sufficient  range  for  the 
representation  of  time  (References  1  and  2). 

'Ihis  paper  also  suggests  a  more  complete 
solution  to  the  overhead  problem — move  both  the 
clock  and  the  task  scheduling  functions  iiumiuily 
implemented  in  software  into  a  concurrency 
management  coprocessor. 


HACKGROUND 

One  of  the  main  purposes  envisioned  for  the 
Ada  language  was  the  programming  of  real-time 
embedded  systents  (Reference  2).  A  real-time 
system  is  a  system  containing  real-time  tasks.  A 
real-time  task  is  a  task  that  has  timitig  constraints 
(e.g.,  a  deadline).  Timing  constraints  may  be  hard 
or  .soft.  A  hard  tinting  constraint  must  always  be 
met  (otherwise  the  system  would  fail).  A  soft 
timing  constraint  .should  be  met  if  possible,  but 
missing  the  constraint  docs  not  cause  system  failure. 
Fundamental  to  real-time  systems  is  the  concept  of 
time.  Real-time  systems  operate  in  an  environment 
of  .severe  timing  constraints,  with  hard  deadlines 
imposed  on  computations  and  input/output  (I/O). 

Some  a; ,  ;i'  -tions  require  very  high  periodic 
l'.'■oces'■  ..i-  >,  In  Equation  I,  the  parameter  f/fut 

represe  ; :  •  ••■ocessor  utilization.  (When  the 
utilizat'  • ;  ;s  ,  the  processor  is  \00%  utilized.) 


i^  =  f/(n)  (,) 

1=1  ‘ 

where  Cj  and  7;  are  the  execution  time  (including 
overhead)  and  period  of  task  q,  respectively.  It  is 
clea.--  that  processor  utilization  increases  with  either 
increasing  compute  time  or  decreasing  (tcriod.  If  an 


overhead  function  (e.g.,  rendezvous)  has  a  short 
compute  time,  a  sufficiently  short  period  may  yield 
100%  utilization.  For  this  reason,  missile 
applic.-^tions,  with  their  .short  periods,  require 
extremely  short  compute  time  for  both  application 
and  overhead  functions.  High  rates  in  the 
application  may  also  require  a  finer  resolution  in  the 
representation  of  time  and,  consequently,  require  a 
higher  overhead  cost  to  maintain  the  representation 
of  time. 


Because  of  inadequate  hardware  support  and  a 
marketing  imperative  to  cover  the  largest  set  of 
target  computers,  existing  Ada  nm-time  systems  are 
software  intensive.  As  a  result,  a  large  portion  of 
the  time  available  for  the  application  on  the 
processor  must  be  spent  updating  the  real-time 
clock,  managing  the  various  scheduling  queues,  and 
.scheduling  tasks.  Many  hard  real-time  applications, 
.such  as  missiles  and  robotics  (Reference  3). 
generally  use  all  of  the  time  that  the  processor 
provides.  If  a  significant  portion  of  the  processor's 
time  would  be  devoted  to  managing  Ada  tusking,  it 
could  make  the  difference  between  using  Ada 
tasking  and  writing  a  custom  concuirency 
management  system  or  a  cyclic  executive. 


Some  specific  overhead  functions  that  may 
require  a  large  percentage  of  the  processor's  time 
are  related  to  time  and  scheduling.  For  one  Ada 
implementation,  1  found  that  the  interrupt  required 
to  support  package  CALENDAR'S  notion  of  time- 
of-day  and  the  delay  statement,  with  0.1  millisecond 
granularity  imposed  by  the  application,  required 
greater  than  30%  of  the  processor's  time. 
Addressing  time  management  with  software  alone 
can  consume  a  significant  percentage  of  the  total 
processor  utilization.  As  task  raies,  tolerances  on 
task  rates  (Reference  4),  and  the  application 
utilization  of  the  processor  become  more  severe,  a 
solution  must  be  found  to  free  more  time  for 
applications.  One  author  (Reference  4)  suggests. 
"With  the  ongoing  interchanges  in 
hardware/software  trade-offs  for  improved 
performance,  the  future  may  reveal  specialized 
liardware  to  alleviate  some  of  these  (real-time 
performance)  problems."  Although  the  importance 
of  hardware  support  was  recognized  early  by  some 
(Reference  5),  general  recognition  of  this  need  is 
growing  slowly  in  the  real-time  community  as 
evidenced  by  papers  appearing  in  journals 
(References  6  and  7),  by  papers  presented  at  real¬ 
time  workshops  (Reference  1),  and  by  some 
products  directed  toward  real-time  (Reference  8) 
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TIME  MANAGEMENT  COPROCESSOR 

Fundamental  to  the  management  of  tasks  ate 
data  structures,  such  as  delay  queues  and  ready 
queues,  and  functions,  such  as  reading  time,  setting 
alarms,  and  queue  management.  One  way  to  reduce 
the  time  spent  by  the  processor  on  overhead 
functions  is  to  off-load  the  bulk  of  the  run-time 
system's  time  management  overhead  onto  a 
coprocessor.  The  time  management  coprocessor 
would  be  a  hardware  clock  that  would  not  need  to 
interrupt  the  processor  at  a  high  rate  to  provide  a 
fine  granularity  software  clock.  Because  this  device 
would  contain  a  delay  queue,  the  mn-time  would  not 
need  to  implement  or  maintain  a  delay  queue.  The 
coprocessor  would  contain  a  priority-sorted  ready 
queue  and  would  not  need  to  interrupt  the  processor 
to  signal  an  expired  delay  unless  the  delayed  task  has 
a  higher  priority  than  the  currently  active  task.  For 
example,  if  a  delay  interval  is  requested,  the  interval 
would  be  added  in  the  coprocessor  to  the  current 
time,  and  the  event  identifier  and  resulting  time 
would  be  placed  automatically  on  the  Delay  queue. 
Upon  expiration  of  the  delay,  the  event  identifier 
and  priority  would  be  moved  automatically  to  the 
priority-sorted  Ready  queue.  These  capabilities 
would  replace  the  software  delay  queue  and  some 
ready  queue  management  with  simple  memory 
references.  They  could  also  reduce  the  number  of 
intcrnipts  required  to  support  overhead  functions. 


Time  Queue— The  Time  queue  is  a  time-ordered 
queue  that  contains  the  scheduled  event  time,  an 
event  identifier  (usually  the  task  identifier),  and 
the  task  priority  (see  the  section  titled  Periodic 
Execution). 

Ready  Queue — ^The  Ready  queue  is  a  priority- 
ordered  queue  of  events  for  which  the  scheduled 
time  has  expired.  This  queue  contains  the  event 
identifier  and  the  task  priority  for  each  expired 
event. 

Time  Registers — This  section  contains  all  the 
registers  required  for  operations  within  the 
device: 


CURRENT  PRIORITY— set  by  the  run-time 
system  to  the  priority  of  the  currently 
executing  task  (see  the  section  titled  Delay 
Scheduling).  Because  this  register  is,  as  arc 
all  registers,  memory  mapped,  the  time 
required  to  update  the  priority  is  the  same  as 
writing  an  integer  to  a  memory  location 
during  a  task  switch. 

YEAR_NUMBER — as  derived  from  the  64-bit 
representation  of  time  (see  the  section  titled 
Representation  of  Time). 


MAJOR  COMPONENTS 


Figure  I  depicts  the  major  functional  blocks  and 
general  interfaces  required  for  the  time  management 
coprocessor. 
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Figure  1.  Time  Management  Coprocessor. 


'Ihe  major  components  of  the  device  would  be 
the  following: 


64-bit  Timer — ^The  least  significant  bit  represents  1 
nanosecond.  The  count  represents  the  number 
of  nanoseconds  since  00:00, 1  January  of  some 
user-defined  year  (see  the  section  tilled 
Representation  of  Time)  or  a  count  of 
nanoseconds  since  initialization  of  the  timer. 


MONTH_NUMBER— as  derived  from  the  64- 
bit  representation  of  time  (sec  the  .section 
tilled  Representation  of  Time). 

DAY_NUMBER— as  derived  from  the  64-bit 
representation  of  time  (.see  the  section  titled 
Representation  of  Time). 

SECONDS.NUMBER— as  derived  from  the  64- 
bit  representation  of  time  (sec  the  section 
titled  Representation  of  Time). 

NANOSECONDS_NUMBER~as  derived  from 
the  64-bil  representation  of  time  (see  the 
section  titled  Representation  of  Time). 

T1MB_NUMBER — for  the  64-bit  representation 
of  time  (see  the  section  tilled  Representation 
of  Time). 

STATUS  REGISTER— -indicates  overflow, 
underflow,  sign,  zero,  a  negative  or  zero 
delay,  or  a  delay_up.til  scheduled  for  a  time 
tliat  has  passed  (see  the  sections  titled  Time- 
Related  operations  and  Delay  Scheduling). 

COMMAND  REGISTER — commands  to  control 
and  set  the  mode  of  the  copiocessor  are 
written  to  this  register  by  the  processor  (see 
the  section  titled  Time  Management 
Coprocessor  Functions). 

SAMPLE  CLOCK  REGISTER— for  the  current 
count  when  commanded  under  hardware 
conu-oJ  (see  the  section  titled  Initial  Setting). 
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UPDATE  REGISTER — for  a  predetermined 
number  of  the  least  significant  bits  to  replace 
the  corresponding  bits  in  the  current  time. 
This  is  done  under  hardware  control  (see  the 
section  titled  Clock  Synchronization). 

ALU — ^An  arithmetic/logic  unit  (ALU)  is  used  for 
performing  arithmetic  time  operations  (see  the 
section  titled  Time-Related  Operations). 

Interrupt  Control — Interrupts  the  processor  if  the 
event  at  the  top  of  the  Ready  queue  is  of  a 
higher  priority  than  the  priority  in  the 
CURRENT  PRIORITY  register. 

Internal  Control — Executes  commands  and  controls 
the  components  of  the  time  management 
coprocessor. 

Host  Processor  Bus  HO — Controls  communications 
with  the  host  processor. 


REPRESENTATION  OF  TIME 

With  the  time  management  coprocessor,  time 
would  be  internally  represented  as  a  64-bit  "ount  of 
nanoseconds.  There  are  two  related  reasons  for  the 
coprocessor  to  use  a  count  of  nanoseconds.  First,  to 
provide  for  a  monotoi  ic  clock  during  distributed 
system  clock  synchronization,  a  finer  timer 
granularity  may  be  required  than  for  any 
application  task  (see  the  section  titled  Clock 
Synchronization).  Second,  although  nanosecond 
granularity  is  not  required  for  most  applications 
today,  1  believe  that  any  attempt  at  addressing 
timing  issues  should  address  longer  tcim 
possibilities. 

The  time  may  come,  with  faster  applications 
(aircraft,  missiles,  etc.)  and  higher  speed  processors 
(gallium  arsenide  (GaAs)-based  processors 
(References  9  and  10)  for  example),  that  nanosecond 
granularity  may  be  required.  However,  the  device 
could  be  designed  to  increment  only  those  sub¬ 
second  bits  that  are  appropriate  for  current 
teclmology.  For  instance,  if  the  hardware 
tcclmology  supported  a  1 -megahertz  clock  rate  (1 
microsecond  granularity),  the  ten  least  significant 
bits  of  the  nanosecond  field  from  an  applications 
point  of  view  would  always  be  zero  on  output  and 
"don't  care"  on  input  (see  the  section  titled  Clock 
Synchronization).  This  64-bit  representation  would 
support  over  290  years  of  nanoseconds,  which 
should  be  enough  for  most  Ada  applications.  Tlie 
run-time  system  or  application  could  read  or  write 
directly  to  the  device  using  the  64-bit  (nanosecond 
count)  representation  of  time.  However,  the  most 
common  representation  would  be  the  following; 

nanoseconds — representing  nanoseconds  less 

than  a  second  (30  bits  minimum) 

seconds — representing  second  of  the  day  (17  bits 

minimum) 

r/ays— -representing  day  of  the  month  (5  bits 
minimum) 


months — representing  month  of  the  year  (4  bits 
minimum) 

years — representing  absolute  or  relative  years 
(10  bits) 

Each  of  these  would  be  an  integer  value  written 
to  a  separate  address  on  this  memory-mapped 
device.  When  the  derived  representation  is  written 
to  the  appropriate  address,  the  device  would 
internally  convert  the  derived  representation  to  the 
64-bit  nanosecond  count  representation  for  use  in 
setting  the  clock,  setting  a  delay,  or  setting  another 
of  the  time-related  functions.  Time  representation 
could  also  be  read  from  the  device  in  the  derived 
(by  automatic  conversion)  or  the  64-bit  nanosecond 
count  (direct)  format. 


TIME  MANAGEMENT  COPROCESSOR 
FUNCTIONS 

Several  functions  are  required  by  this  device  to 
support  the  run-time  system.  The  following  is  not 
intended  to  be  an  exhaustive  list,  but  only  to 
represent  some  basic  commands. 

SETTING  THE  CLOCK 

Initial  Setting 

To  .set  the  clock,  the  user  would  write  the 
current  time  in  either  the  internal  or  the  derived 
format.  It  would  be  necessary  to  enter  only  the 
parameters  of  time  that  are  of  interest  to  the 
application.  For  example,  in  a  missile  application, 
time  of  flight  and  not  absolute  time  is  the  more 
appropriate  representation.  Tlie  user  could, 
therefore,  initialize  the  clock  to  zero  time  at  the 
start  of  the  mission.  For  shipboard-,  ground-,  or 
space-based  applications,  the  user  may  require  the 
fuM  representation  of  time:  a  nanosecond  count  from 
a  user-specified  time.  Whether  the  time  used  is 
relative  or  absolute  would  be  determined  by  a  mode 
command  issued  to  the  coprocessor. 

Clock  Synchronization 

In  distributed  applications,  the  need  for  clock 
synchronization  becomes  apparent.  Clock 
synchronization  takes  two  fonns:  start-up 
synchronization  and  correction  for  drift.  If  the 
application  required  setting  the  clock  to  the  value  of 
a  master  clock,  this  could  be  done  in  one  or  two 
stages,  depending  upon  the  application  and  its 
required  accuracy.  The  first  stage  would  involve 
copying  the  time  from  a  "standard"  clock  to  the 
coprocessor  and  then  issuing  the  set  clock  command. 
(This  first  stage  should  be  nonpreemptable.)  The 
second  stage  is  the  synchronization  process. 

Staii-up  synchronization  and  correction  for  drift 
(Reference  4)  could  be  accomplished  in  a  similar 
manner.  If  time  were  sensed  to  have  drifted,  the 
user  would  have  the  ability  to  correct  the  time  with 
three  levels  of  processor  interaction,  depending 
upon  the  accuracy  required. 
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Full  processor  involvement — the  processor  is  a 
critical  element  in  the  accuracy  of  the 
synchronization  process.  An  example  of  this 
type  of  synchronization  is  given  in  the 
previous  paragraph. 

Partial  processor  involvement — the  processor  is 
involved;  however,  processor  timing  is  not 
critical  to  the  accuracy  of  the  synchronization 
process. 

Processor  independent — the  processor  is  not 
involved  in  the  synchronization  process  on  a 
continuing  real-time  basis. 

One  method  for  partial  processor  involvement 
would  involve  a  hardware-based  signal  for  the 
coprocessor.  The  coprocessor  would  be  equipped 
with  a  sample  clock  input  that  would  force  the  clock 
to  immediately  copy  the  counter  to  the  SAMPLE 
CLOCK  register.  The  processor  would  next  copy 
the  SAMPLE  CLOCK  register  of  a  master  clock  to 
the  coprocessor.  The  processor  would  then  issue  the 
subtract  and  update  command.  Tliis  command 
would  cause  the  coprocessor  to  subtract  the  master 
clock  time  sample  from  the  value  in  the  SAMPLE 
CLOCK  register  and  then  add  the  result  to  the 
current  time.  Tliis  method  could  incur  an 
unacceptably  large  processor  overhead.  Also,  if  the 
clock  were  being  used  for  timing  measurements,  the 
results  would  not  be  acceptable. 

A  method  to  implement  the  third  fonn  of 
synchronization  would  involve  the  processor  only 
during  system  initialization.  During  initialization, 
the  processor  would  enter  a  predetermined  number 
of  the  least  significant  bits  into  the  UPDATE 
register.  At  an  appropriate  interval,  the  master 
clock  would  issue  a  hardware-based  update 
command  to  the  coprocessor.  The  coprocessor, 
upon  receipt  of  this  command,  would  copy  the 
UPDATE  register  into  the  least  significant  bits  of 
the  current  time.  If  the  bits  set  in  this  process  are 
less  significant  than  the  granularity  required  by  the 
application,  time  monotonicity  is  assured. 

'fhese  are  some  of  the  simpler  clock 
synchronization  schemes  that  could  be  used. 
However,  the  device  should  be  compatible  with 
approaches  taken  in  bus  standards,  such  as 
Futurebus+  (Reference  11). 

Delay  Scheduling 

To  implement  the  current  Ada  delay  statement, 
the  run-time  system  would  write  the  delay  time  (in 
either  representation  of  the  section  titled 
Representation  of  Time),  the  task  priority,  and  the 
task  identifier  (TID)  and  then  write  the  command  to 
set  delay.  Internally,  the  device  would  add  the  delay 
to  tlie  current  time  and  then  enter  the  absolute 
expiration  time  into  the  Time  queue  along  with  the 
priority  and  the  TID  associated  with  the  event.  If 
the  requested  delay  is  zero  or  negative,  this  will  be 
flagged  in  the  STATUS  REGISTER  (see  the  section 
titled  Major  Components),  and  the  information  for 
the  task  will  be  placed  directly  in  the  Ready  queue. 


For  each  count  of  the  64-bit  timer  (which  could 
represent  1  nanosecond  for  a  1 -gigahertz  time-base 
clock,  1  microsecond  for  a  1 -megahertz  time-base 
oscillator,  etc.),  the  device  would  compare  the 
earliest  time  on  the  Time  queue  with  the  current 
time.  When  the  current  time  is  greater  than  or 
equal  to  the  scheduled  time,  the  priority  and  TID 
would  be  transferred  to  the  Ready  queue. 

The  priority  and  TID  of  the  highest  priority 
runnable  task  would  always  be  readable  by  the  run¬ 
time  system.  If  the  ran-time  system  has  written  a 
value  to  the  CURRENT  PRIORITY  register,  the 
device  will  wait  until  the  highest  priority  runnable 
task  has  a  priority  greater  than  the  CURRENT 
PRIORITY  register  before  it  generates  an  interrupt. 
To  disable  the  interrupt,  the  run-time  system  would 
write  the  voiue  of  PRIORITY'LAST  to  the 
CURRENT  PRIORITY  register.  To  always  be 
interrupted  when  a  delay  expires,  the  nm-time 
system  would  write  the  value  of  PRIORITY'FIRST 
to  the  CURRENT  PRIORITY  register. 

A  delay _until  statement  (Reference  12)  operates 
in  a  similar  fashion.  The  difference  is  that  the 
absolute  time  for  expiration  is  entered  when  a  set 
delay_until  command  is  issued  to  the  device.  If  the 
scheduled  time  has  passed,  this  will  be  flagged  in  the 
STATUS  REGISTER  (see  the  section  titled  Major 
Components),  and  the  information  for  the  task  will 
be  placed  directly  in  the  Ready  queue. 

Other  Scheduling  Operations 

If  a  task  required  removal  from  either  the 
Ready  queue  or  the  Time  queue  when  a  task 
temiinaies,  is  aborted,  or  completes  a  timed  entry 
call,  the  run-time  system  would  write  the  TID  to  the 
device  and  then  write  a  coprocessor  command  to 
delete  the  Time  queue  entry  or  to  delete  the  Ready 
queue  entry. 

If  a  task  priority  must  be  changed,  the  mn-time 
system  would  write  the  TID,  the  new  priority,  and 
the  change  priority  command  to  the  coprocessor. 
This  would  change  the  priority  of  all  occurrences  of 
that  task  in  both  queues. 

Time-Related  Operations 

The  following  functions  would  be  available  from  the 
device: 

•  Convert  a  64-bit  representation,  written  by 
the  run-time  system  or  application  program, 
to  YEAR.NUMBER,  MONTH  NUMBER, 
DAY  NUMBER,  SECONDS  NUMBER,  and 
NANOSECONDS_NUMBER  (Reference  2). 

•  Convert  YEAR  NUMBER, 

MONTH  NUMBER,  DAY  NUMBER, 
SECONDS  NUMBER,  and 
NANOSECONDS.NUMBER  to  the  64-bit 
representation. 

•  Add  an  interval  to  the  current  time,  in  either 
the  derived  format  or  the  64-bit  format,  to 
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the  current  time.  The  output  would  be 
available  in  either  the  derived  format  or  the 
64-bit  format. 

•  Subtract  the  clock  from  a  time  in  the  future. 
The  input  would  be  in  either  the  derived 
format  or  the  64-bit  format.  The  output 
would  be  available  in  either  the  derived 
format  or  the  64-bit  format.  This  operation 
would  also  allow  comparison  of  the  current 
time  with  a  given  time  with  the  result 
available  from  the  STATUS  REGISTER  (see 
the  section  titled  Major  Components). 

OTHER  OPERATIONS 
Watchdog  or  Alarm  Functions 

A  watchdog  or  alarm  function  would  be  treated 
like  a  delay  statement  or  delay_until  statement  by 
die  coprocessor;  however,  if  no  TID  wouid 
normally  be  associated  with  the  watchdog  or  alarm 
function,  the  run-time  system  would  fabricate  a 
special  identifier  >0  flag  the  function.  The 
advantage  of  having  the  watchdog  function  as  part 
of  the  same  device  is  that  the  priority  of  the 
watchdog  expiration  would  be  sorted  with  the 
priorities  of  the  tasks  in  the  Ready  queue.  Because 
watchdog  priorities  are  combined  with  task 
priorities,  the  application  will  not  have  a  high 
priority  event  interrupted  by  a  low  priority  event. 

A  user,  for  example,  may  not  want  the  "fight  fire" 
task  interrupted  by  the  "popcorn  ready"  interrupt. 

Periodic  Execution 

Through  the  addition  of  another  field  and  more 
control  logic  in  the  Time  queue,  automatic 
rescheduling  of  periodic  tasks  could  be  supported. 
The  additional  field  in  the  Time  queue  would 
represent  the  period  of  the  associated  task.  On 
expiration,  the  TID  and  priority  would  be  moved  to 
the  Ready  queue.  The  device  would,  on  finding  a 
nonzero  period  field,  add  the  period  to  the  expired 
delay  time  for  the  task  and  then  enter  the  new  time, 
the  priority,  and  the  TID  into  the  Time  queue.  If 
the  periodic  task  terminated,  the  run-time  system 
would  write  the  appropriate  delete  command  to  the 
coprocessor  (see  the  section  titled  Other 
Operations). 

IMPLEMENTATION  OPTIONS 
Reduced  Capability  Implementations 

The  discussion  here  has  centered  on  producing  a 
device  that  has  full  capability  to  support  run-time 
system  time-related  functions.  While  this  is 
desirable,  a  device  with  less  functionality  could  also 
improve  system  performance.  The  basic  timer 
elements  required  to  support  the  run-time  system 
(Figure  2)  are  the  64-bit  timer,  an  expiration  time 
register,  and  a  time  comparator.  With  this  basic 
device,  the  run-time  system  would  keep  a  time- 
sorted  queue  of  time  events  and  write  each  event 


Figure  2.  Time  Management 
Coprocessor  Essentials. 


time  to  the  device  immediately  after  the  current 
timer  event  expires  or  as  a  new  event  precedes  the 
current  timer  event.  This  simple  implementation 
would  require  an  interrupt  only  when  a  scheduled 
event  expired.  The  run-time  system  or  the 
application  could  read  the  current  time. 

While  the  coprocessor’s  requirements  could  be 
implemented  in  today's  gate  array  technology 
(Reference  13),  it  is  unlikely  that  a  1 -nanosecond 
clock  granularity  will  be  required  for  the  processors 
being  designed  into  systems  today.  A  granularity  of 
0.1  microsecond  should  be  easily  achieved  and 
should  cover  the  majority  of  applications  today.  A 
processor  based  upon  VllSlC  Phase  II  or  GaAs 
technology  could  support  0.01  microsecond  or  less 
granularity  because  of  their  100+  megahertz  clock 
rates  (References  9  and  13). 

Other  pieces  of  the  full  coprocessor  may  be 
added  to  the  basic  timer  depending  upon  their 
relative  contribution  to  run-time  system  overhead. 

If  the  operations  involved  in  combining  various  time 
units  into  the  nanosecond  count  and  deriving  those 
time  units  from  the  nanosecond  count  are  a  larger 
burden  than  queue  management,  they  would  then  be 
implemented.  Coprocessor  implementation  with  an 
ALU  could  supersede  implementation  of  a 
comparator  for  signaling  the  expiration  of  a 
scheduled  event.  It  is  also  clear  that  many  more 
run-time  system  functions  could  be  added  to  this 
type  of  coprocessor  and  result  in  reduced  overhead 
in  the  run-time  system  (Reference  6). 

Coprocessor  Versus  On-Chip 

One  question  must  be  addressed  to  ensure 
compiler  vendor  support  and  applicability  to  the 
broadest  number  of  systems.  Should  the  time 
management  device  be  implemented  as  a 
coprocessor  in  a  separate  package  from  the 
processor  (off-chip)  or  integrated  with  the 
processor  on  a  single  chip?  I  believe  the  device 
should  initially  be  implemented  off-chip. 

The  following  are  some  technical  advantages  of 
on-chip  implementation. 

•  Signal  propagation  delays  involved  in 
communicating  with  an  off-chip  device  may 
be  ten  times  thooc  of  an  on-chip  device. 
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•  Less  power  would  be  required  by  an  on-chip 
device. 

•  A  smaller  footprint  would  be  required  for  an 
on-chip  device. 

•  Potential  performance  gains  exist  from 
integrating  the  timer  registers  and  commands 
with  those  of  the  processor. 

The  technical  advantages  of  on-chip  devices 
must  wait  until  experience  with  them  is  gained  and 
the  market  for  them  is  developed.  The  following 
are  advantages  of  the  off-chip  time  management 
coprocessor. 

•  The  coprocessor  device  can  be  designed  to 
work  with  a  variety  of  processors  currently  in 
use  for  real-time  applications.  This  flexibility 
would  provide  a  broader  market  base  for  the 
device. 

•  The  selection  of  an  appropriate  timer  could  be 
independent  of  the  selection  of  an  appropriate 
processor. 

Implementing  the  off-chip  coprocessor  first  and 
then  following  that  with  development  of  the  on-chip 
device  was  the  approach  taken  successfully  with  the 
floating-point  coprocessor  and  memory  management 
units  (see  the  section  titled  Summary  and 
Conclusions). 


SUMMARY  AND  CONCLUSIONS 

In  the  past,  we  have  seen  software  floatiiig-poim 
arithmetic  performed  to  the  detriment  of  real-time 
system  performance.  Now  we  have  hardware 
floating-point  coprocessors.  In  die  past,  we  have 
had  software-intensive  memory  management 
systems.  We  now  have  hardware  memory  manage¬ 
ment  coprocessors.  Both  of  these  devices  have 
relieved  the  processor  of  a  computational  burden 
shared  by  many  applications.  At  the  present  time, 
we  have  software-intensive  "time  management"  as 
evidenced  in  the  Ada  run-time  systems  where 
software  manages  the  delay  queues,  ready  queues, 
time  scheduled  events,  etc.  We  need  similar 
hardware  support  for  real-time  performance  to 
make  Ada  viable  for  a  broader  range  of  real-time 
systems. 

A  time  management  coprocessor  could  be  easily 
implemented  with  today's  gate  array  technology,, 
although  it  would  probably  be  limited  to  0.1 
microsecond  granularity.  The  main  issue  in  the 
design  of  the  coprocessor  is  to  ensure  that  it 
interfaces  properly  with  a  broad  range  of  processors 
(Reference  13). 

A  time  management  coprocessor  should  be  only 
a  first  step  in  moving  more  overhead  functions  into 
the  hardware.  Implementations  of  this  device  could 
range  from  the  basic  device  in  Figure  2  to  the  more 
complete  device  shown  in  Figure  1.  While  this 


coprocessor  has  the  potential  of  relieving  the 
processor  of  some  overhead,  a  more  complete 
solution  is  required.  The  more  complete  solution 
includes  moving  time  management  ftinctions, 
scheduling  algorithms,  and  other  concurrency 
management  functions  from  the  run-time  system  and 
conipiier-generated  code  into  a  concurrency 
management  coprocessor  (References  4,  6,  and  10). 
Tnc  concurrency  management  coprocessor  has  been 
demonstrated  by  I  uuu  University  as  a  practical  and 
feasible  way  to  build  computer  systems.  This 
solution  will  never  be  applied  if  the  design  of 
computing  systems  is  maintained  as  separate 
hardware  and  software  entities. 

We  are  now  entering  an  era  that  requires  and 
can  support  a  new  view  of  system  design — a  view 
inspired  by  the  need  for  higher  speed  and  more 
correct  complex  systems.  The  foundation  for  this 
new  view  is  based  upon  powerful  hardware  and 
software  tools  that  have  developed  along  similar 
lines  (e.g.,  silicon  compilers,  VHDL,  software 
compilers,  Ada).  What  appears  to  be  lacking  are 
methods  to  support  the  work  and  system  engineers 
with  appropriate  expertise  (Reference  10).  The 
work  discussed  here  is  dramatic  evidence  of  the 
potential  of  taking  a  new  view  of  system  design. 
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0.  RAcunA 

Lea  Aquipements  de  pilotage  et  guidaqe 
dAveloppAs  par  SEXTANT  Avionique  posaAdent 
dea  architecturea  de  plua  en  plua  com- 
plexea  et  la  part  du  logiciel  eat  aana 
ceaae  croiaaante. 

Pour  rApondre  A  cea  nAceaaitAa,  SEXTANT 
Avionique  a  mia  en  oeuvre  un  atelier  de 
dAveloppement  de  logiciela  de  pilotage  et 
guidage.  Get  atelier  eat  conatituA 
d'outila  et  de  paaaerellea  communicantea 
aaaurant  la  cohArence  aur  tout  le  cycle  du 
dAveloppement . 

VISA  (Validation  Interactive  da 
SpAcificationa  Avioniquea)  permet  la  for¬ 
mulation  dea  apAcificationa  at  offre  la 
poaaibilitA  de  lea  rendre  exAcutablaa, 
pour  d'une  part,  Avaluer  trAa  tOt  leur 
comportement  dynamique  (maquettaga)  et 
d' autre  part,  vArifiei  le  comportement  en 
tempa  rAol  da  I'Aquipement  apAcifiA  (pio- 
totypage) . 

La  conception  et  la  rAaliaation  du  logi- 
ciel  aont  facilitAea  par  I'emploi  d'outila 
de  gAnAration  autoroatique  de  code  de 
1' atelier  : 

•  GALA  (CAnAration  ilutomatique  de 
lioglciel  Avionique)  gAnAre  le  code 
exAcutable  dea  fonctiona  de  pilotage 
et  guidage  A  partir  dea  apAcificationa 
dAtaillAea  dAcritea  dana  le  langoqe 
graphique  aoiia  VISA. 

•  GALI  (SAnAration  Automatique  de 
Ijogiciel  d' Interface)  gAnAre  le  coda 
exAcutable  de  traitement  dea 
entrAea/aortiea  dAcritea  dana  le  die- 
tionnaire  de  donnAea  soua  VISA. 

L' intAgration  et  la  validation  a'effec- 
tuenc  en  pluaieura  phasea.  Le  Banc  de 
Validation  Avionique  (BVA)  a  pour  ob^ectif 
de  aimplifier  la  miae  en  oeuvre  et 
1' exploitation  dea  rAaultata  de  cea  teats. 
Lea  outila  de  1' atelier  aont  placAa  dana 
one  atructure  d'?'Ooueil  PALAS  (Eroduction 
^S3i!,t6e  de  Logiciel  d' Application 
BtructurAe)  aaaurant  la  cohArence  de 
1 ' ensemble . 


1 .  Introduction 

La  conduite  du  vol  eat  un  dea  mAtiers  de 
base  de  SEXTANT  Avionique. 


Dana  le  domaine  de  la  conduite  du  vol 
civil,  la  participation  de  SEXTANT 
Avionique  A  la  gamme  Airbus, commencAe  au 
tout  dAbut  dea  annAea  70, a  AtA  marquAe  par 
certaines  “premiAres"  qui  ont  conatituA 
dea  avancAes  technologiques  marquantea: 

•  systAmes  d’ atterriasage  automatique 
tout  temps  avec  une  hauteur  de  dAci- 
aion  (HD)  progressivement  amenAe  A 
zAro, 

•  dAveloppement  aur  A300-B4  du  premier 
FFCC  (Facing  Forward  Crew  Coclcpit) , 
pilotage  A  deux,  basA  aur  un  systAme 
de  conduite  du  vol  numArique, 

«  commandea  de  vol  Alectriques  d'abord 
aur  l'A310  pour  lea  gouvernes  secon- 
daires,  puis  globalement  aur  l'A320, 

•  intAgration  dea  fonctiona  de  conduite 
et  de  gestion  du  vol  pour  A320,  puis 
A340  dans  un  seul  calculateur. 

Dans  le  domaine  de  la  conduite  du  vol 
militaire,  SEXTANT  Avionique  participe  A 
la  dAfinition  et  A  la  rAaliaation  dea 
pilotes  automatiquea  de  tous  lea  avions 
d'armea  frangais  Lea  derniers  Aquipements 
fournis  concernent  lea  diffArentes  ver¬ 
sions  du  Mirage  2000  (DAfense  aArienne, 
Export,  N  et  D),  lea  avions  ATL-2 
(patrouilleur  maritime),  le  C135FR  (ravi- 
taille’ir  en  vol  do  I'arraAe  do  I'air  fran- 
gaise)  et  I'hAlicoptAro  franco-alleraand 
TIGRE. 

Pour  le  RAFALE,  SEXTANT  Avionique  conduit 
dea  travaux  aur  I'approche  et  I'appontage 
automatique,  aur  I'approche  et  I'attorris- 
sage  aur  terrain  do  fortune,  fonctiona  de 
pilotage  automatique  intAgrAes  dans  le  CET 
(Calculateur  d' Elaboration  de 
Ira jectoires) . 

Cea  Aquipements  ae  caractArisent  : 

•  par  dea  architectures  fonctionnelles 
et  matArielles  de  plus  en  plus  com¬ 
plexes, 

•  par  une  numAriaation  quasi-totale, 
induisant  des  volumes  de  logiciel  en 
accroissement  permanent, 

•  par  des  dAveloppements  A  dAlai 
constant,  impliquant  une  maltrise  du 
cycle  de  dAveloppement  au  travers 
d'outils  performants  et  d'une  organi¬ 
sation  industrielle  adAquate. 
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Tous  c*s  programoMS,  dAvaloppAa  da  plua  an 
plua  an  larga  partanariat,  rapoaant  aur 
daa  tachnologiaa  da  pointa,  daa  loglciala 
at  daa  Aquipamanta  A  haut  nlvaau  da  a4cu- 
rit4. 

Cette  communication  inaiste  sur  les  exi¬ 
gences  en  matidre  de  oualit6  de  logiciels 
qui  ne  peuvent  Stre  assur6es  qu'au  travera 
d'une  m6thodoloaie  riooureuse  couvrant  le 
cycle  de  vie  complet.  La  formalisation  de 
cette  mSthodologie  A  I'aide  d'outils 
informatiques  est  un  atout  suppl^mentaire 
A  la  satisfaction  de  ces  exigences. 

La  communication  d6crit  dans  I'ordre  habi¬ 
tual  du  cycle  de  d6veloppement  du  produit 
1' ensemble  des  m6thodes  et  outils  mis  en 
place  par  la  soci6t6  SEXTANT  Avionique 
pour  la  specification/  la  conception/  la 
realisation/  1' integration  et  la  valida¬ 
tion  des  equipements  de  conduits  du  vol  et 
souligne  la  coherence  de  I'ensemble  au 
travers  de  passerelles  communicantes . 

Les  activites  concernAes  par  I'Alaboration 
d’ equipements  avioniques  sont  rAparties 
classiqueinent  dans  un  cycle  en  V  et  repr6- 
sentent  successivement  ; 

•  la  formulation  des  exigences  (speci¬ 
fication)  et  la  recherche  des  solu¬ 
tions  permettant  de  les  satisfaire 
(conception) , 

•  la  realisation  (materiel  et  logiciel) 
iinpiementant  les  solutions/ 

•  1' integration  et  la  validation  fonc- 
tionnelle  globale  de  I'Aquipement. 

La  demarche  entreprise  a  pour  but  d'arri- 
vor  au  niveau  de  detail  final  selon  une 
methods  d' analyse  descendants/  en  assurant 
une  tragabilite  dans  le  developpement  et 
de  lier  les  diffArentes  phases  au  travers 
d'outils  dAdiAs  A  chaque  t4che  et  compa¬ 
tibles  entre  eux  : 

•  VISA  (  Validation  Interactive  de 
Specifications  Avioniques)  pour  les 
tAches  de  specification  / 

•  GALA  (Generation  Automatique  de 
Logiciel  Avionique)  et  GALI 
(Generation  Automatique  de  Logiciel 
d' Interface)  pour  les  tAches  de 
conception  et  de  realisation  du  logi- 
ciel/ 

•  le  Banc  de  Validation  Avionique  (BVA) 
pour  les  tAches  d' integration  et  de 
validation  fonctionnells/ 

•  PALAS  ™  (Production  AssistAe  de 
Logiciel  d' Application  Structure) 
pour  I'organisation  du  pro^et  et  la 
gestion  de  configuration. 


ATELIER  DE  DEVELOPPEMENT  DE  LOGICIELS  DE 
PILOTAGE  GOIDAGE 


2  Specification/  naquattagS/  prototypaga 
2.1  Specification 

VISA  est  un  outil  dAveloppA  par  SEXTANT 
Avionique  congu  dans  le  cadre  d'un  mAtier 
particulier  dont  le  savoir-faire  est  par- 
faitement  stabilise  :  le  developpement  de 
logiciels  de  pilotage-guidaqe .Visa  est 
utilise  pour  1 'elaboration  do  la  specifi¬ 
cation  globale  puis  detaillAe.Il  a  Ate 
eiaborA  avec  le  souci  de  satisfaire  aux 
contraintos  imposAes  par  les  collabora¬ 
tions  industrielles  multi-partenaires  : 

•  diversite  des  mAthodos  et  outils  de 
redaction  du  cahier  des  charges  qui 
peut  se  presenter  sous  forme  de  speci¬ 
fication  globale  ou  dAtaillAe. 

•  partage  des  tAches  et  communication 
des  specifications  organisAes  dans  un 
cadre  contractual . 

Los  difficultAs  sont  surmontAes  grAce  A  la 
modularite  de  1' outil  et  A  un  support 
roAthodologique  rigouroux. 

VISA  rApond/  de  plus,  aux  besoms  suivants 


•  accroltre  la  qualitA  et  la  fiabilitA 
de  la  specification  produite  au  tra¬ 
vers  d’une  description  structurAe  et 
non  ambiguB/ 

•  valider  la  specification  avant  Ij 
phase  de  realisation. 

•  integrer  la  documentation  . 

Analyse  descendant* 

La  specification,  fcimulation  des  exi¬ 
gences,  se  decompose  en  plusieurs  phases, 
avec  un  niveau  de  detail  croissant.  Ces 
phases  aboutissent  A  des  formulations  dif- 
fArenteS/mais  cohArentes  entre  elle3,du 
cahier  des  charges. 
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I>a  specification  globale  s'appuie  sur  une 
methods  de  decomposition  fonctionnells, 
herites  de  la  methods  SART,  suivant  Is 
formalisms  propose  par  HATIiEY.  Le  concep- 
teur  affine  progressivement  les  fonctions 
necsssairss  A  la  realisation  du  cahier  des 
charges  et  precise  les  flux  de  donnees 
associees.L' architecture  generals  du  pro- 
duit  est  ainsi  mis  en  place  et  est  utili¬ 
ses  pour  construire  une  gestion  de  confi¬ 
guration  (entites  et  liens  de  dependance 
inter-entites)  et  initialiser  les  phases 
suivantes  du  developpement . 

Specification  detailiea 

La  phase  de  specification  detaillAe  est 
precedes  d'une  etude  preiiminaire  da  la 
structure  des  lois  de  pilotage  et  de  la 
mise  au  point  des  solutions  repondant  au 
besoin,  Cette  tiche  eat  realises  avec 
I'aide  d'outils  d'AAO  (Automatique 
Assistee  par  Ordinateur) . 

Lea  solutions  sont  ensuite  formalisAes 
grice  A  un  langage  graphique  trAs  proche 
de  celui  de  1' automaticien.  Une  biblio- 
thAque  de  fonctions  standardisAea  est  dis- 
ponible  et  comprend,  entre  autrea,  des 
fonctions  da  type  arithmetique,  trigonomA- 
trique,  logique  et  des  fonctions  plus  com¬ 
plexes  telles  que  filtre,  intAgrataur. 
retard,  moyenne,  limiteur.  Ce  langage  sera 
dAcrit  plus  prAcisAment  au  §3. 

Lea  solutions  sont  dAveloppAea  conformA- 
ment  au  dAcoupage  fonctionnel  et  A  la 
definition  des  flots  de  donnAes,  issus  do 
la  phase  de  specification  globale.  Elies 
sont  trAs  finement  dAtaillAes  afin  de  per- 
mettre  un  codage  direct. 

La  representation  qraphique  de  1' ensemble 
do  la  specification  est  le  vocteur  privi- 
lAgiA  de  la  communication  grace  A  son  for¬ 
malisms  clair,  non  ambigu  et  accessible  A 
diffArents  niveaux  d' abstraction  (dAcompo- 
•sition  hiArarchique  descendants)  .  Elle  est 
rendue  indispenrable  du  fait  de  la  diver- 
sitA  des  intervenants. 

Base  de  donnAes 

L' analyse  du  cahier  des  charges  dAbouche, 
comme  on  I'a  vu,  sur  1' elaboration  d'une 
specification  globale,  puis  dAtaillAe, 
finalisant  ainsi  la  bonne  comprehension  du 
problAme  et  I'assurance  de  la  faisabilitA 
thAorique.  Les  informations  susceptibles 
d'etre  utilisAes  dans  plusieurs  phases  du 
developpement  (types,  natures,  destina¬ 
tions  des  flots  de  donnAes,  attiibuts  des 
elements  caractAristiques)  sont  extraites 
de  ces  specifications  et  sont  ordonnAes 
dans  une  base  de  donnAes  (BO) ,  appelAe  BD 
interne,  qui  est  exploitAe  pour  assurer  la 
coherence  de  la  specification  et  apporter 
un  complement  pratique  d' informations  A 
ceiie-ci . 


La  specification  est  parallAlement  complA- 
tAe  par  la  definition  des  entrAes/sorties 
de  I'Aquipement,  Agalement  ordonnAes  dans 
une  deuxiAme  BD,  appelAe  BD  externe.  Son 
exploitation  permet  d'Alaborer  un  document 
officiel,  livrA  avec  I'Aquipement  pour  en 
specifier  les  connexions. 

Ces  deux  BD  sont  UtilisAes  con jointement 
et  des  relations  permettent  d'en  croiser 
les  informations. 

Gestion  et  docustentation  intAgrAos 

II  est  indispensable  de  conserver  A 
1' ensemble  une  coherence  constante,  tant 
au  niveau  du  contenu  que  de  la  configura¬ 
tion.  En  phase  de  developpement,  les  enri- 
chissements  sont  multiples  et  la  charge  de 
travail  imposAe  par  les  tAches  de  gestion 
requiert  une  mobilisation  importante., 
Aussi,  il  est  apparu  indispensable  d'y 
associer  un  guide  mAthoriologique  prAcis, 
reposant  sur  les  principes  suivants  ; 

■  centralisation  et  transmission  verti¬ 
cals  des  informations  A  travers 
1' exploitation  de  la  BD  interne,  lors 
des  diffArentes  phases  de  specifica¬ 
tion  (contrfiles  croisAs  sur  le  conte¬ 
nu,  analyse  de  coherence  et  de  complA- 
tude,  repercussion  des  modifications, 
consultation  ergonomique) , 

•  gestion  de  configuration  globale, 
dAfinissant  les  liens  de  dApendance 
entre  AlAments  de  diffArentes  phases. 

De  mAme,  1' eiat>oration  de  la  documenta¬ 
tion,  selon  une  norme  prAcise,  rAclame  la 
plus  grande  rigueur  mAthodologique  et  est 
avantageusement  supportAe  par  un  outil  de 
PAO  (Publication  AssistAe  par  Ordinateur) . 

Ces  diverses  tAches  font  partie  integrants 
do  1' atelier.  Lour  traitement  on  apparait 
alors  moms  contraignant,  laissant  aux 
intervenants  plus  de  disponibilitA  pour 
les  tAches  affArentes  A  la  recherche  de 
solutions  rApondant  aux  exigences  fonc- 
tionnellcs. 

Outile 

Les  mAthodes  prAsentAes  ci-dessus  sont 
mises  en  oeuvre  par  des  progiciels  qui 
sont,  chacun,  dAdiAs  A  une  partie  distinc- 
te  da  la  specification.  Chaque  outil  pos- 
sAde  un  contrdle  intAgrA  de  coherence  et 
de  syntaxe,  de  la  partie  qu'il  est  charge 
de  dAcrire,  ainsi  qu'une  BD  propre. 

L' outil  VISA  possAde  une  structure  modu- 
laire,  dont  les  coroposants  de  base,  pour 
la  specification,  sont  STP™  (stA  IGL  sup- 
portant  SART) ,  un  Aditeur  graphique 
SAFIRS™  (st6  ASSIGRAPH) .  Ces  outils  peu- 
vent  Stre  remplacAs  par  des  outils  equiva¬ 
lents  pour  satisfaire  les  besoms  spAci- 
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fiques  d'activit6a  dans  le  cadre  de  coop6- 
rations  industrielles. 

L'outll  de  gestion  de  configuration 
(PAIAS™  cf  §5)  et  le  gestionnaire  des  BD 
interne  et  externe  (ORACLE™)  assurent  la 
coherence  de  1' ensemble. 

Ces  outils  sont  intfegris  dans  une  structu¬ 
re  d'accueil  A  interface  conviviale  et 
1' ensemble  constitue  un  atelier  cohArent 
et  un  vaste  outil  de  communication  infor- 
matique  graphique,  prAcis,  et  efficace 
pour  les  Aquipes  d'Atudes,  les  Aquipes 
systAmes  et  les  Aquipes  de  dAveloppement 
logiciel. 


2.2  Kaquettage 

Les  specifications,  aux  diffArents  niveaux 
d' abstraction,  no  sauraient  Stro  finali- 
sAes  sans  la  possibilitA  d'evaluer  leur 
COTupGrcdmuuu  uyTioiTil^uo  Uxcia  LoL  ctatts 
cycle  de  developpement.  II  est  nAcessaire 
d' introduire  dans  le  cycle  do  dAvolpppe- 
ment  des  mini-cycles  de  validation,  asso- 
cies  aux  phases  qui  le  composent,  permet- 
tant  de  s' assurer  que  les  specifications 
issues  d'une  phase  repondent  aux  besoms 
pour  lesquels  elles  ont  ete  etablies.  Ces 
operations  de  validation  s'appuient  sur  le 
maquettage,  pour  lequel  VISA  assure  la 
traduction  automatique  de  la  specification 
dans  un  langage  de  simulation. 

Ce  maquettage,  mene  en  paralieie  i  I'Acii- 
ture  des  specifications,  necessite  : 

•  une  representation  logicieile  de  la 
specification,  rAalisee  en  grande  par- 
tie  grAco  4  des  traduoteurs  automa- 
tiques,  ce  qui  llraito  les  risques 

d' erreurs, 

•  une  modeiisation  de  1' environneraent 

de  l'6quipement  ayant  pour  but  do  don- 
ner  un  comportoment  realiste  aux 
ontrees/sorties  des  functions  speci- 
f lees, 

•  un  environnement  de  conduits  de  simu¬ 
lation  et  d'analyse  de  rAsultats. 

Un  effort  particuiier  est  port6  sur  la 
presentation  des  rAsultats  des  simula¬ 
tions,  ceux-ci  etant  inserables  dans  le 
document  d' ensemble  de  la  specification. 

La  gestion  de  configuration,  plus  souple 
pour  le  maquettage  que  pour  la  specifica¬ 
tion,  est  neanraoins  sous-gacente  et  appor- 
te  A  la  phase  de  maquettage  une  demarche 
rigoureuse  et  precise  (une  simulation  est 
realisee  A  partir  d'un  certain  etat  de  la 
specification,  dans  un  contexts  precis 
etc...;,  la  gestion  de  configuration  permet 
d'en  retrouver  et  d' identifier  le  domaine 
de  oouverture  thAorique) . 


Le  code  image  de  la  specification  est  eia- 
bor6  A  I'aide,  principalement,  do  traduo¬ 
teurs  automatiques  developpAs  A  SEXTANT 
Avionique  : 

*  SART/ADA  pour  la  specification  globa- 
le, 

*  GALA  pour  la  specification  detaillAe 
dont  chaque  element  reprAsente  un  ele¬ 
ment  terminal  de  la  representation 
fonctionneile  (une  PSPEC  dans  le  for- 
malisme  SART  ) , 

•  un  gAnArateur  de  code  exploitant  les 
informations  des  BD  interne  et  oxter- 
ne,  pour  les  declarations 

d'  entrAes/sorties . 

La  conduite  de  simulation  est  conviviale: 

•  interface  graphique  (visualisation, 
poste  de  commande. . . ) , 

'  interactivitA  (lancement/arrAt  des 
essais,  definition  des  enregistre- 
ments/stimuli,  modifications  des  para- 
mAtres  internes  de  la  specification) . 

Le  dialogue  entre  les  functions  A  tester 
(1' image  de  la  specification)  et  leur 
environnement  se  fait  par  envoi/rAception 
de  messages  inter-processus,  ce  qui  permet 
de  faire  communiquer  des  langages  diffA- 
rents  tels  que  C,  Le-Lisp,  Fortran  et  ADA. 


2.3  Prototypage 

Ce  teime  dAsigne  ici  une  operation  qui 
relAve  de  la  mAme  demarche  que  le  maquet¬ 
tage  avec  la  difference  que  1' animation 
des  fonctions  est  effectuAe  en  temps  rAel . 
Ceci  se  3ustifie  pour  les  functions  dont 
la  validation  nAcessite  la  presence  d' ele¬ 
ments  rAels  ; 

•  certaines  fonctions  font  intervenir 
le  pilote  et  ne  peuvent  Atre  validAes 
qu'en  prAsence  d'un  opArateur  rAagis- 
sant  en  temps  rAel  : 

•  de  meme,  il  peut  etre  nAcessaire  de 
valider  une  fonction  dialoguant  avec 
une  autre  en  la  plagant  dans  le 


contexte  r^aliste  cr66  par  la  presen¬ 
ce  d'un  equipement  reel  supportant 
cette  autre  fonction. 


En  phase  de  prototypage,  VISA  intAgre  les 
contraxntes  temps-r6el  du  logiclel .  Ces 
contraintes  sent  du  ressort  de  la  realisa¬ 
tion  logicielle,  mais  sent  prises  en 
compte  lors  de  la  specification  detailiee. 
Ceci  souligne  la  n6cessit6  do  conaid6rer 
le  pro^et  dans  son  ensemble  en  liant 
etroitement  les  differentes  phases  les 
unes  aux  autres,  tout  en  procedant  A  un 
aff inage  progressif:  le  maquettage  ayant 
valide  les  contraintes  amont  (cahier  des 
charges) ,  le  prototypage  pr6voit  le  com- 
portement  de  la  specification  soumise  aux 
contrajntes  aval  ou  A  1' environnement 
reel.  Ces  contraintes  sont  modeiisees  pour 
cette  tAche. 

Nous  verrons  au  §4  que  la  validation  quan¬ 
titative  s'appuie  avantageusement  sur  des 
resultats  de  simulations,  genAres  par 
I'outil  de  prototypage. 


guphiqu*.  , 
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Les  besoms  pour  le  prototypage  sont  du 
memo  ordre  que  pour  le  maquettage  :  dispo¬ 
ser  d'outils  pour  produire,  A  partir  d'une 
specification  globale,  un  code  executable 
image  de  la  fonction  sp6cifiee,  et  pour 
mettre  en  oeuvre  ce  code  dans  un  contexte 
temps  reel.  Ces  outils  utilisent  les  ros- 
sourcos  du  Banc  de  Validation  (of  §4) . 


3.  Conception  •t  realisation  du  logiciel 


Les  resultats  des  activites  de  specifica¬ 
tions,  maquettage  et  prototypage  sont 
exploites  dans  les  phases  de  conception  et 
de  realisation. 

La  conception  et  le  soh6raa  global  dans 
lequel  se  place  la  structuration  logiciel¬ 
le  des  equipements  de  pilotage-guidage 
sont  parfaiteraent  maltris6s.  Ces  equipe- 
raents  entront  dans  la  categorie  des  sys- 
t6mes  reactifs  qui  r6agissent  continQment 
e  leurs  entiees  pour  recalculer  cyclique- 
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ment  leurs  sorties.  La  phase  de  conception 
de  ces  equipements  peut  se  schematiser  en 
une  repartition  des  elements  de  la  speci¬ 
fication  detainee  dans  des  modules  logi- 
ciels  en  fonction  de  contraintes  d' implan¬ 
tation  du  logiciel. 

Dans  les  equipements  de  pilotage  et  guida- 
ge,  une  faible  partie  du  volume  de  code 
est  constituee  de  logiciel  commun  reutili- 
se  sur  d' autres  calculateurs.  C'est  le  cas 
du  moniteur  temps  reel,  d'une  bibliothAque 
de  fonctions  avioniques  de  base  et  d'une 
partie  des  tests  de  sAcurite  et  de  mainte¬ 
nance  integree.  La  plus  grande  partie  du 
logiciel  est  trAs  specif ique  d'un  calcula- 
teur  donne.  Dans  le  cas  du  pilote  automa- 
tique  de  I'Airbus  A320,  la  repartition  en 
volume  des  fonctions  specifiques  du  pilo¬ 
tage  automatique  est  la  suivante  ; 

•  45%  pour  les  calculs  de  logique  et 
lois  de  pilotage, 

•  30%  pour  la  gestion  des  entree/sor¬ 
ties, 

•  20%  pour  les  sequencements, 

•  5%  pour  diverses  fonctionnalitAs . 

La  part  de  logiciel  est  de  plus  en  plus 
importance  dans  les  equipements,  mais  les 
deiais  impartis  A  la  realisation  restent 
constants.  L' utilisation  d'outils  do  gene¬ 
ration  automatique  do  code  est  done  un 
moyen  d'augmenter  la  productivite  tout  en 
malcrisant  la  qualite  du  logiciel  produit. 

II  apparait  judicieux  de  genArer  automati- 
quement  le  code  dos  fonctionnalitAs  ropr6- 
sentant  le  plus  fort  pourcencago  de  volume 
de  code  sujet  A  de  frequences  modifica¬ 
tions.  Ainsi  GALA  est  un  outil  gAnerant 
automatiquement  le  code  du  calcul  de  la 
logique  et  des  lois  de  pilotage,  tandis 
que  GALI  gAnAre  le  code  de  la  gestion  des 
ontrAes/sorties. 

Les  outils  de  gAnAiation  de  code  GALA  et 
GALI  dAveloppAs  par  SEXTANT  Avionique  sont 
fondAs  sur  I'approche  suivante  : 

La  gAnAration  automatique  du  code  des 
modules  logiciels,  nAcessite  la  formalisa¬ 
tion  d'un  langage  de  spAcification 
dAtaillAe,  La  gAnAration  autoisatique  d'un 
module  logiciel  est  alors  la  transcription 
exacte  de  la  specification  de  ce  module, 
dAcrit  A  I'aide  de  ce  langage,  en  code 
source  acceptable  par  un  compilateur. 


3.1  GAIA  '.  SAnAration  ^utosiatique  de 
J^giciel  Avionique 

GALA  (Generation  Automatique  de  Logiciel 
d' Avionique)  gAnAre  automatiquement  le 
code  source  exAcutable  des  modules  logi- 
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ciels  sp6cifi6s  sous  forme  graphique  ainsi 
que  la  documentation  assocr^e. 

3.1.1  Lm  langag* 

Le  mSroe  langage  est  utilise  pour  la  speci¬ 
fication  d6taill6e  sous  VISA  et  pour  la 
programmation  par  GALA. 

II  s'apparente  aux  langages  A  flot  de  don- 
nAes  synchrone,  avec  lesquels  un  systAme 
est  reprAsente  par  un  rAseau  d'opArateurs 
connectAs  par  des  liaisons. 

Un  opArateur  (un  symbole  graphique)  reprA- 
sente  une  fonction.  Une  liaison  (un  fil) 
reprAsente  une  donnAe. 

Ce  formalisme  prAsentent  les  avantages 
suivants  : 

•  II  «>?t  particuliArement  bien  adaptA  A 
la  description  des  automatismes  et  de 
la  logique  opArationnelle, 

•  La  syntaxo  est  simple  et  bien  dAfi- 
nie, 

•  Les  contraintes  de  sAquencement  dans 
1' execution  d'un  programme  rAsultent 
uniquement  des  dependences  fonction- 
relles  entro  les  variables, 

•  Les  temps  da  reaction  des  opArateurs 
du  rAseau  sont  supposes  nAgligeables 
par  rapport  aux  cadences  de  circula¬ 
tion  des  donnAes  (cadences  dAfinies 
par  le  cycle  d' activation) .  Cette 
hypothAse  perraet  de  faire  abstraction 
des  contraintes  temporelles. 

Cheque  symbole  graphique  correspond  A  une 
fonction  dAcrite  par  un  algorithme  validA 
et  certifiA  et  A  un  sous-programme  codA 
dans  le  langage  ciblo.  L' ensemble  des 
fonctions  esc  regroupA  dans  une  biblio- 
thAque. 

Cette  bibliothAque  est  extensible.  Quand 
un  projet  identlfie  un  nouveau  sous-pro¬ 
gramme  utilisA  de  fagon  rApAtitive,  il 
suffit  de  crAer  un  symbole  graphique  avec 
la  caractAcisatlon  de  ses  broches  de 
connexion,  puis  do  le  valider  et  de  1' ins¬ 
taller  dans  la  bibliothAque. 

Les  informations  complAmentaires  nAces- 
saires  au  codage  sont  prises  on  compte  par 
1 ' intermAdiaire  da  paramAtres  associAs  aux 
symboles . 

3.1.2  L' utilisation 

Le  processus  de  production  de  logiciel  par 
GALA  se  dAroule  en  plusieurs  phases  : 

•  Edition  des  diagrammes.  Dans  le  cadre 
de  I'atelier,  cette  Adition  est 
effectuAe  pendant  la  phase  de  spAci- 
fication  dAtaiilAe  (VISA). 


•  Analyse  et  contrAle  de  cohArence  du 
diagramme  en  accord  avec  un  certain 
nombre  de  rAgles  syntaxiques  (par 
example,  toute  broche  de  symbole  doit 
Atre  connectAe)  et  sAmantiques  (par 
example,  si  un  chemin  de  donnAes  com- 
porte  une  boucle,  un  opArateur  de 
mAmorisation  doit  Atre  obligatoirement 
prAsent  sur  cette  boucle) .  Une  partie 
de  ces  contrAles  est  effectuAe  sous 
VISA  en  phase  de  spAcification. 

•  GAnAration  automatique  de  code  en 
deux  Atapes  :  d'abord  la  gAnAration  de 
code  symbolique  indApendant  du  langa¬ 
ge,  suivi  de  la  traduction  de  ce  code 
symbolique  dans  le  langage  de  program¬ 
mation  cible. 

L' utilisation  d'un  nouveau  langage  de  pro¬ 
grammation  cible  pour  un  projet  donnA 
implique  seulement  le  changement  du  tra- 
ducteur  final.  Les  traducteurs  disponibles 
actuellement  sont  :  PASCAL,  PLM,  FORTRAN 
et  ADA. 

3.2  GXLI  :  QAnAratlon  Automatique  de 
liogiaiel  d' Interface 

Le  langage  de  spAcification  utilisA  par 
GALI  est  un  langage  textual  propre  aux 
traitements  des  entrAes/sorties. 

GALI  s'appuie  sur  une  base  de  donnAes 
contenant  les  caractAristiques  de  tous  les 
signaux  on  entrAe  et  en  sortie  d'un  Aqui- 
pement.  Cette  base  de  donnAes  est  rensei- 
gnAe  en  phase  de  spAcification. 

Le  concepteur  enrichit  la  dSfinition  des 
signaux  en  y  apportant  des  informations 
coroplAmentaire  (des  contraintes  logi- 
cielles  par  example) .  GALI  assure  alors  la 
dAfinition  et  la  mise  A  ]Our  du  dAcoupago 
fonctionnel  en  relation  Atroite  avec 
I'outil  de  gestion  de  configuration.  Ala- 
bore  la  documentation  d’ interface  de 
I'Aquipement  et  les  spAcif ications  de 
codage  dans  le  langage  appropriA  . 

GALI  gAnAre  le  code  des  modules  de  traite¬ 
ments  d'entrAes  sorties  en  conformitA  avec 
leur  spAcification  de  codage  ainsi  quo  les 
modules  de  dAclaration  des  donnAes  afin 
d'en  assurer  la  cohArence  avec  leur  envi- 
ronnement.  GALI  utilise  les  mAmes  traduc¬ 
teurs  que  GALA. 

3.3  Bilan  d’ utilisation 

Les  avantages  apportAs  par  la  gAnAration 
automatique  de  code  sont  importants  : 

Les  outils  de  codage  automatique  GALA  et 
GALI  transcrivent  fidAlement  la  spAcifi¬ 
cation  de  codage  en  langage  de  programme- 


tion.  Aucone  intervention  humaine  n'est 
nScessaire  A  ce  stade. 

Tout  risque  d' introduction  de  d6£aut  de 
codage  est  supprim4,  ce  qui  permet  d'obte- 
nir  beaucoup  plus  rapidement . le  niveau 
requis  de  quality  du  logiciel.Les  tests 
structurels  (tests  unitaires  "boite 
blanche")  des  modules  g4n6r6s  automatique- 
raent  peuvent  §tre  supprim^s. 

Ces  outils  utrlise.it  directement  les 
informations  issues  de  la  specification  et 
apportent  une  facilite  dans  la  tragabilite 
de  ces  informations  ainsi  qu'une  bonne 
coherence  sur  1' ensemble  de  1' atelier  de 
developpement,  dans  lequel  chaque  informa¬ 
tion  n'est  definie  qu'une  seule  fois,  evi- 
tant  les  risques  d' incoherence  d'une 
double  definition.  La  coherence  parfaite 
entre  documents  de  specification  et  code 
executable  et  la  concentration  du  d6velop- 
puur  sur  les  iSches  de  specification  sont 
autant  de  facteurs  suppl6mentaires  de  qua  - 
lite  du  logvciel  produit. 

La  suppression  de  la  phase  de  tests  struc¬ 
turels  (teats  "boite  blanche")  des  modules 
g6n6r63  autcmatiquement  n'est  autoris6e 
par  les  autorites  de  certification  que 
dans  la  mosure  od  lea  outils  ont  ete  qua¬ 
lifies,  ce  qui  est  le  cas  pour  les  pro¬ 
grammes  Airbus  A320  et  A340. 


4.  Integration  at  validation  das  equipa- 
mants 


4 . 1  Methodas 

Cette  partie  traite  de  1' ensemble  des 
ossais  fonctionnels  realises  aprds  inte¬ 
gration  du  materiel  et  du  logiciel. 

Ces  essais  font  suite  aux  tests  realises 
par  les  equipes  de  developpement  materiel 
at  logiciel. 

L'equipe  materielle  aura  integre  les  dif- 
fdrents  elements  du  calculateur,  vdrifie 
les  signaux  d' alimentation,  les  diffe- 
rentes  fonctions  des  cartes,  le  cSblage  de 
fond  de  panier,  effectue  les  auto-tests. 
L'equipe  logicnlle  aura  valide  le  moni- 
teur  temps  reel,  la  blbliotheque  avionique 
GALA.  Les  tests  unitaires  auront  et6 
effectues  pour  les  modules  codds  tnanuelle- 
ment . 

L'ob^ectif  de  ces  essais  fonctionnels  est 
de  verifier  : 

•  I'lntegrite  du  systeme,  c'est  A  dire 
que  toutes  les  fonctions  prevues  pour 
obrenir  la  sOretd  de  fonctionneraent 
sont  correctement  implantdes, 

•  la  conform, ltd  de  I'dquipement  rdalisd 


par  rapport  aux  diffdrents  documents 
de  specification  (interface,  lois  de 
pilotage,  logique  opdrationnelle) 

Les  operations  d' integration/validation 
s'organisent  en  quatre  phases  : 

Phase  1  :  Integration  et  Validation  par 
processeur 

Les  objectifs  de  cette  phase  sont  de  veri¬ 
fier; 

•  1' integration  hard/soft  processeur 
par  processeur  sous  1' aspect  intdgrite 
(tests  de  sdcuritd,  auto-tests) 

•  les  dialogues  inter-processeurs. 

Les  outils  utilises  sont  les  bancs  de  test 
de  I'dquipement  et  les  moyens  d' investiga¬ 
tion  associds,  tels  qu'analyseur  logique 
et  dmulateur. 


Phase  2  :  Tests  en  boucle  ouverte  (1  avion 
n'est  pas  dans  la  boucle) 

Les  tests  boucle  ouverte  s'effectuent  sur 
un  calculateur  complot  et  fermd  (tests 
boite  noire) . 

Dans  cette  phase  de  test,,  les  sorties  de 
I'Aquipemont  (ordres  gouvernes  et  manettes 
des  gaz)  ne  sont  pas  envoydes  A  I'environ- 
nemont  simuld. 

Les  objectifs  de  cette  phase  sont  de  veri¬ 
fier  : 

•  le  comportement  dynaroique  du  systdme 
sous  les  aspects  architecture  gdnerale 
et  sdquencement  temps  r6el, 

•  les  flots  de  donnees  A  I'lnterieur  du 
systdme, 

•  globalement  le  monitoring. 

Los  tests  boucle  ouverte  sont  repartis  en 
deux  sous-phases  ; 

La  logique  comprend  A  la  fois  la  logique 
operationnelle  liee  au  contr61e  du  vol  par 
I'equipage  et  la  surveillance  et  reconfi¬ 
guration  des  entrdes/sorties  de  I'dquipe- 
ment. 

Sont  te.stes  dans  cette  phase  les  engage¬ 
ments  des  modes  et  des  sous-modes  au  moyen 
des  postes  de  commande  de  I'dquipement 
ainsi  que  les  affichages  des  diffdrentes 
informations 

Le  but  de  cette  phase  de  test  est  une 
validation  dvnamique  et  quantitative  de  la 
function,  par  exemplc  :  une  tenue  de  cap, 
d' altitude  ou  d'lLS. 
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Le  calculateur  repoit  un  ensemble  de 
signaux  coh6rents  correspondant  i  une 
configuration  avion  donn4e  aur  lesquels  se 
superposent  un  ou  plusieurs  stimuli. 

Le  principe  retenu  est  un  recoupement 
quantitatif  par  rapport  i  des  simulations 
e££ectu6es  sur  un  logiciel  image  implant^ 
sur  un  ordinateur  sol  (mainframe  ou  sta¬ 
tion  de  travail) . 

Des  sollicitations  du  type  Echelon,  cr6- 
neau  ou  rampe  sont  appliqu^es  sur  les 
entries  capteurs,  i  la  fois  sur  l'6quipe- 
ment  r6el  et  la  function  simul6e. 

La  mise  en  oeuvre  est  effectu^e  sur  le 
Banc  de  Validation  Avionique  (BVA) . 

Ehase  3  :  Tests  en  boucle  ferm6e  (1' avion 

est  dans  la  boucle) 

L'ob^ectif  de  cette  phase  est  de  tester  le 
comportement  en  dynamique  de  I'Aquipement 
dans  les  phases  r6elles  de  vol. 

Dans  cette  phase,  le  calculateur  regoit 
les  rAponses  de  1' avion  aux  commandes 
gAnArAes  par  lui-mAme  au  travers  d'une 
modAlisation  fine  da  1 ' environnement 
(avion,  moteur,  capteurs,  autres  Aquipe- 
ments  en  relation  avoc  I'Aquipement  on 
test) . 

La  principe  retenu  est  un  recoupement 
quantitatif  par  rapport  4  des  simulations 
effectuAes  sur  un  logiciel  image  implantA 
sur  un  ordinateur  sol, 

Les  stimuli  sont  maintenant  issus  des 
postes  de  commands  avion  du  pilots  automa- 
tique  tela  que  le  pilots  peut  les  onvoyer 
“en  situation"  dans  des  conditions  opAra- 
tionnelles  de  vol, 

Tous  les  modes  sont  ainsi  testAs  :  modes 
de  croisiAre  ou  d' atterrissage  automatique 
ainsi  que  la  logique  d' enchalnament  des 
modes  et  de  leura  dlffArents  Atats  (modes 
arraAs,  actifs, etc, , , , ) 

Dans  cette  phase  1' ensemble  do  la  fourni- 
ture  est  prAsente  aur  le  Banc  de 
Validation  Avionique  :  postes  de  commando, 
afficheurs  de  mode,  contiguration  multi- 
calculateurs , 

Phase  4  :  Tests  de  non-rAgression  des 
Atats  successifs  du  systAme 

Des  tests  de  non  rAgression  des  Atats  suc¬ 
cessifs  de  I'Aquipement  sont  effectuAs  sur 
des  scAnarii  de  vol  complets,  Les  rAponses 
de  I'Atat  n+1  sont  comparAes  aux  rAponses 
de  I'Atat  ii  pour  les  foncLions  non  raodi- 
fiAes  entre  les  deux  Atats,  La  mise  en 
oeuvre  est  effectuAe  de  fagon  automatisAo 
sur  le  banc  do  Validation  Avionique  (BVA). 

4.2  Evolution  das  mAthodas  da  validation 

Une  Avolution  des  if  hodes  orientAe  vers 
1' automatisation  du  passage  des  procAdures 


de  test  est  en  cours. 

En  effet,  le  passage  des  tests  rAclame  un 
ensemble  d' actions  de  I'opArateur  sur  le 
banc  : 

•  configuration  de  1' environnement  de 
simulation  :  choix  de  la  version  de 
simulation,  de  ses  conditions  d' ini¬ 
tialisation, 

•  prAparation  du  calculateur  4  tester  : 
reset,  auto-tests, 

•  actions  sur  les  postes  de  commande 
avion  :  engagement  du  calculateur, 
engagement  de  modes,  sAlection  de 
consignes . . . , 

•  commandes  sur  les  moyens  d'espionnage 
et  de  sollicitation  du  banc. 

Deux  difficultAs  sont  identifiAes  dans  ce 
processus  manuel  : 

a)  Le-d6teimini3me 

Lors  d'un  tost  cffoctuA  manuellement,  les 
actions  de  I'opArateur  interviennent  4  des 
instants  alAatoires. 

Or  certains  tests  (tests  de  recoupement 
avec  une  simulation  effectuAe  sur  un  logi- 
ciel  image,  tests  de  non  rAgression) 
nAcessitent  de  respecter  un  chronogrammo 
prAcls  d' enchalnement  des  actions. 

machinea,  at.dea  honmiaa 

La  comple,xitA  croissante  des  fonctions  des 
calculateurs  provoque  une  augmentation  du 
volume  des  tests  de  validation.  II  dovient 
nAcessaire  do  libArer  I'opArateur  des 
t.lches  rApAtitives  of  in  qu'il  puisse  se 
concentror  sur  le  oontrOle  des  rAsultats. 

Ces  deux  difficultAs  mettent  en  Avidence 
la  nAcessitA  de  pouvoir,  par  un  automate, 
“simuler"  I'opArateur,  ou  tout  au  moms 
celles  de  ses  actions  : 

•  qui  doivent  Atre  exAcutAes  plus  rapi- 
deroent  que  ne  le  permet  le  temps  de 
rAaction  d'un  opAratour, 

•  qui  ne  nAcessitent  pas  un  niveau 
d' expertise  important. 

L'outil  en  cours  de  mise  au  point  rApondra 
aux  deux  ob^ectifs  ; 

•  dArouler  automatiquement  des 
sAquences  d' actions  dAterministes, 

•  exAcuter  des  tests  en  “batch". 

Ces  deux  niveaux  d' utilisation  de  I'auto- 
mate  sont  basAs  sur  des  mAcanismes  qui 
s'appuient  sur  la  structure  existante  du 
banc  par  ajout  d'une  couche  "simulation  de 
I'opArateur"  au  dessus  des  entrAes  "clas- 
siques"  de  l'outil. 
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L' automate  pourra  agir  aur  tout  le  Banc, 
constitu6  de  mat^riels  et  de  logiciela 
h^t^rogtoes  :  stations  de  travail,  sta¬ 
tions  graphiques,  ordinateurs  temps-r^el, 
moyens  de  trac6,  boltiers  de  coupure... 

4.3  L'outil  :  la  Banc  da  Validation 
Avioniqua  (BVA) 

Le  BVA  est  un  ensemble  de  materials  et  de 
logiciels  pormettant  de  taster  les  logi- 
ciels  des  calculateurs  embarqu6s.  II  est 
utilis6  dans  tous  lea  programmes  civils  et 
militaires  majeurs  dans  lesquels  SEXTANT 
fournit  des  fequipements  de  conduite  du  vol 
:  Airbus  A310,  A320,  A340,  hdlicoptAre 
franco-allemand  TIGRE,  Mirage  2000, 

C135FR,  puis  RAFALE,  pour  le  GET 
(Calculateur  d’£laboration  de 
Irajactoiros) . 

Architactura  fonctionnalla 

Un  banc  est  constitu^  : 

•  d'une  simulation  temps  r^el  aur  cal¬ 
culateur  de  typo  GOOLD/ENCORE  oompre- 
nant  ; 

un  moniteur  de  simulation  char- 
g6  de  la  coordination 
d' ensemble, 

-  les  modiilaa  avion,  moteur,  cap- 
taurs, 

-  une  interface  temps  r6el  char¬ 
gee  des  ^changes  avoc  les 
autros  oonstituants  du  banc. 

•'  d'une  interface  op^rateur  aur  station 
do  travail  en  frontal  du  calculateur 
principal  supportant  tout  le  dialogue 
de  conduite  de  simulation  et  de  mise 
en  oeuvre  des  moyens  d'essai  avec  fonr- 
tlons  de  stimulation,,  d' aspionnage,  et 
de  selection  des  enregistrements, 

graphiquo  do  type  Silicon  Graphics  (en 
1' absence  de  I'environnement  rOel), 

•  d'un  pupitre  dans  lequel  viennent 
s'insOrer  : 

-  une  "planche  de  bord"  avec  les 
oldraents  rOels  du  poste  do 

I  .  1  Otago  (postes  de  com,i.ande 
PA,,  visualisations  61ectro- 
niques) 

-  des  commandes  cockpit 
(bees,  volets,  tram,  d6ro- 
freins, . . . ) , 

-  des  ospionneurs  d' entrees-sor- 
ties, 

-  des  traceurs  rapides, 

-  des  tiroirs  do  coupure  d' ali¬ 
mentation, 

-  les  supports  calculateurs. 

•  d'une  chalne  d'.ontrfees-sorties  per- 
raettant  le  couplage  de  la  simulation 
temps  del  avec  le  ou  lea  equipoments 
A  valider  d'une  part  et  le  pupitre 


d' autre  part. 

Le  banc  est  reli6  A  un  poste  de  tracA  et 
d’aide  A  1' analyse  des  rAsultats  d'essai. 

Evolutions  vars  un  Banc  pour  systAmas 
IntAgxAs 

Deux  axes  d'Avolution  sont  envisages  : 

•  Alargir  le  nombre  d' Aquipements  qu'il 
peut  accueillir  pour  valider  des  sys- 
tfemes  intAgrAs  d'avionique  coroprenant 
par  example  das  capteurs  et  des  visua¬ 
lisations, 

•  avoir  la  capacity  de  remplacer  pro- 
gressivement  en  cours  d' integration 
les  elements  prototypes  par  les  ele¬ 
ments  reels. 


5.  Outil  da  gastion  da  configuration 

PALAS  :  Eroduction  AssistAe  de  Logiciel 
d' Application  Structure 

Le  developpe.ment  du  logiciel  d'un  Aquipe- 
mant  de  pilotage-guidage  est  confronte  A 
des  contraintes  importantes  : 

•  le  cycle  do  d6ve  lopi.ement  est  court 
pour  tenir  des  deiais  de  plus  en  plus 
rAduits, 

•  les  fonctionnalites  A  intAgrer  am6- 
nent  A  embarquer  un  volume  croissant 
de  logiciel,, 

•  le  cycle  de  vie  de  I'Aquipement  est 
loi.g  et  I'environnement  de  d6veloppo- 
mont  est  susceptible  d'Avoluer, 

•  la  sAcurite  et  la  fiabilitA  du  dAvo- 
loppement  sont  preponderant s,, 

•  la  nAcessite  de  fairo  vivre  plusiours 
variantes  d'un  mAme  logiciel,  au  mAme 
rythme  et  en  parallAle. 

La  prise  en  compte  de  cos  contraintes  rend 
ndcessaire  1 ' utilisation  d'une  structure 
d'accueil  facilitant  la  gestion  des  evolu¬ 
tions  des  projets  et  1 ' integration  des 
divert  outils  logiciels  utilises,  tout  au 
long  des  phases  de  specification,  concep¬ 
tion,  codage.  tests  unitaires,  integra¬ 
tion,  validation  et  maintenance. 

PALAS  rApond  A  1' ensemble  de  ces  besoms. 
C'est  une  structure  d'accueil  de  haut 
niveau  qui  prend  en  compte  1' ensemble  des 
dimensions  d'un  dAveloppement  logiciel. 

Les  principales  functions  oflertes  par 
PALAS  sont  : 

•  la  structuration  d'un  produit  logi¬ 
ciel  en  arborescence  avec  liens, 

•le  oontrole  dos  accAs  et  intertaoe 
utilisateur,. 
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•la  construction  et  le  tests  des  confi¬ 
gurations, 

•la  raise  en  place  de  versions  offi— 
cielles, 

•le  d6veloppement  de  versions  de  logi- 
ciel  en  parall^le, 

•le  contrdle  complet  et  I'enregistre- 
ment  des  modifications, 

•la  gestion  des  historiques  de  tous  les 
composants  logiciels, 

•1' int6gration  des  outils  du  projet. 

5.1  Organisation  du  projat 

PALAS  permet  d'une  part  d' organiser  le 
projet  et  de  connaltre  A  tout  instant 
l'6tat  d'Avolution  de  celui-ci,  d' autre 
part  de  dAfinir  les  tAches  A  rAaliser  par 
chaque  membre  de  I'Aquipe  de  dAveloppe- 
ment. 

PALAS  permet  Agalemont  de  synchroniser  des 
dAveloppements  dans  le  cas  d'un  projet 
partitionnA  en  plusieurs  sous-projets. 
Chaque  utilisateur  PALAS  travaille  dans  un 
"espace  priv6"  qui  lui  eat  propre,  dans  le 
cadre  d'une  tAche  prAalableraent  dAfinie 
par  le  responsable  projet. 

Le  responsable  de  pro3et  peut  dAfinir  des 
autorisations  d'accAs  A  chaque  membre  d'un 
projet.  Le  r61e  de  chacun  est  alors  bien 
dAfini,  ce  qui  induit  : 

•  une  organisation  claire  des  Aquipes 
de  dAveloppement, 

•  une  dAfinition  claire  et  complete, 
pour  chaque  membre  de  I'Aquipe,  de  son 
contexte  de  travail,  ainsi  que  des 
informations  qui  lui  sont  nAcessaires, 

•  le  maaquage  de  certaines  parties  de 
dAveloppement  (par  exemple  dans  le 
cadre  d'une  coopAration  ou  d'une  sous- 
traitance) . 

Chaque  "entitA"  dAfinie  avec  P.ALAS  possAde 
un  norabre  variable  "d'objets"  (de 
fichiers)  assooiAs,,  principalement  identi- 
fiAs  par  les  outils  a'appliquant  sur 
1' ontitA . 

Une  entlte  PALAS  peut  done  correspondre  A 
un  modAle  complet  de  apAcif ication,  A  un 
module  logiciel  (avec  1' ensemble  de  ces 
fichiers  do  documentation,  code  source, 
code  objet  exAcutable. . . ) ,  A  un  ]eu  de 
tests,  etc,...  Ce  concept  permet  de  gArer 
les  composants  produits  lors  des  phases  du 
cycle  do  vie  du  logiciel. 

5.2  Gestion  da  configuration 

La  description  et  1' exploitation  des 
"liens"  entre  les  diffArentes  entitAs  d'un 
proget  permettent  de  mettre  en  oeuvre  des 
mAcanisroes  de  configurations  coroplAtes  ou 
partielles  de  versions  du  logiciel  et  le 


maintien  d' intAgritA  entre  plusieurs  docu¬ 
ments,  par  exen5>le  entre  la  spAoification, 
un  module  logiciel  et  le  rAsultat  des 
tests. 

PALAS  rAalise  entiArement  et  de  fagon 
automatique  toutes  les  tAches  de  gestion 
de  configuration  et  permet  done  de  mainte- 
nir  la  cohArence  entre  1' ensemble  des 
entitAs  d'un  projet,  depuis  I'expression 
des  besoms  jusqu'A  la  raise  en  exploita¬ 
tion,  pour  laquelle  il  dispose  d'un  mAca- 
nisme  de  raise  en  place  de  versions  offi- 
cielles. 

5.3  DAvelopperant  an  parsllAla 

II  est  frAquemment  nAcessaire  de  faire 
vivre  simultanAment  plusieurs  variantes 
d'un  mAme  logiciel.  Ces  variantes  peuvent 
Atre  liAes  A  des  configurations  systAme 
diffArentes  ou  A  diffArents  niveaux 
d'lntAgration.  II  est  alors  important  de 
conserver  1(  plus  grande  part  de  compo¬ 
sants  communs  entre  les  diverse? 
variantes . 

PALAS  offre  toutes  les  commandes  pour 
dAvelopper  en  parallAle  et  continuer  le 
dAveloppement  on  psrallAle  ou  le  faire 
reconverger.  II  autorise  la  gestion  siraul- 
tanAe  du  plusieurs  configurations  d'un 
mAme  sous-ensemble  du  logiciel,  tout  en 
prAservant  des  divergences  les  composants 
communs  A  ces  diffArentes  versions. 

5.4  Suivi  das  aodifications 

PALAS  offre  la  possibilitA  d'Atablir  des 
procAdures  rigourouses  pour  les  modifica¬ 
tions  par  1' intermAdiaire  des  DAcisions 
d' Intervention  logicielle  (OIL).  Les  dAci- 
sions  d' interventions  logicieJles,  qui 
rAsultent  d'une  analyse  d'Avolution,  sont 
dAcrites  sous  PALAS  en  prAcisant  les  enti¬ 
tAs  touchAes  par  chaque  Avolution,  et 
regroupAes  au  sein  de  Rapports  de 
Modification  (RM)  qui  rythment  1' Avolution 
du  logiciel  d'un  Atat  stable  A  un  autre. 

PALAS  rAalise  le  suivi  des  Avolutions  et 
gAre  I'historique  de  chaque  coraposant  du 
proget  ce  qui  permet  d'en  maltriser  I'Atat 
A  tout  instant  du  cycle  do  vie  et  de 
garantir  ainsi  la  sAcuritA  et  la  fiabilitA 
du  dAveloppement. 

5.5  L' intAgration  d' outils 

PALAS  offre  un  ensemble  de  services  pour 
intAgrer  les  divers  outils  utilisA  sur  un 
proget  et  contrAler  le  processus  de  dAve¬ 
loppement  A  travers  la  raise  en  oeuvre  de 
ces  outils. 


PALAS  permet  de  rfeutiliser  des  procedures 
mise  en  place  sur  d'autres  pro jets,  voire 
des  procedures  standardisees  au  sein  d'une 
ent reprise. 

L' integration  d'outils  de  developpement 
logiciel  se  fait  par  1' intermediaire  de 
procedures  de  production  ou  "chalnes  de 
production"  qui  peuvent  aller  du  simple 
appel  A  un  outil,  gusqu'i  1' enchalnement 
complexe  de  plusieurs  outils. 

PALAS  permet  de  definir  des  chalnes  de 
production  fonctionnant  dans  des  environ- 
nements  specifiques  lies  4  I'environnement 
cible  (les  bancs  de  validation  par 
exemple) ,  ou  4  I'environnement  d'un  outil 
(les  stations  de  travail  pour  VISA  par 
exemple) . 

PALAS  permet  de  prendre  en  compte  les 
contraintes  d'h6terogen6ite  de  matAriels 
de  developpement,  at  offre  les  mAcanismes 
nAoessaires  pour  maintenir  I'intAgrite  du 
proget  sans  intervention  manuelle  de 
1' utilisateur . 


PALAS  est  un  outil  industriel  utilise  dans 
le  cadre  des  grands  programmes  :  A320, 
A340,  HAP,  C135FR,  ARIANE  IV. 


6. Conclusion 

L' atelier  de  developpement  do  logiciels  de 
pilotage-guidage  s'appuie  sur  une  raethodo- 
logie  stable,  et  eptouvAe  par  SEXTANT 
Avioniquo  pour  le  developpement  d'un  grand 
nombre  d' equipements .  L' atelier  permet  de 
mettro  en  oeuvre  rigoureusement  cette 
methodologie,  4  travers  I'omploi  d'outils 
adaptes  4  chaque  phase  du  cycle  de  deve¬ 
loppement.  II  assure  la  communication  des 
informati ''ns  issues  de  ces  outils  pour 
couvrir  I'ensemble  de  la  mAthodologie  sur 
tout  le  cycle  de  vie  du  projet. 

L' atelier  est  done  le  garant  d'un  bon 
niveau  de  qualite  des  equipements  reali¬ 
ses  . 
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1.  Introduction 

Las  systAmas  embarquAs  d6velopp6s  par  la 
Division  Conduite  du  Vol  da  SEXTANT 
Avionique  Avoluent  sans  cesse  au  niveau  da 
leurs  fonctionnalitAs,  das  moyens  da  d6ve- 
loppement  at  das  techniques  d' implementa¬ 
tion. 

L' evolution  des  fonctionnalites  peut  Stre 
observAe  sur  deux  plans  : 

-  I'automatisation  de  la  conduite  du  vol 
correspond  A  1' evolution  du  concept  da 
Pilots  Automatique  vers  celui  de 
SystAme  de  Gestion  du  Vol  :  ces  sys- 
tAmes  mettent  A  la  disposition  des 
pilotes  un  ensemble  de  fonctions 
d'aide  au  pilotage,  depuis  I'automati¬ 
sation  de  la  tradltionnolle  tenue  de 
consigne  jusqu'A  I'aida  A  la  reconfi¬ 
guration  du  plan  do  vol  par  la  pilots 
en  cours  de  mission,  avec  prise  en 
compte  de  la  preparation  de  mission  au 
sol,, 

-  do  plus,  1' integration  do  nouvelles 
fonctionnalites  est  rendue  possible 
par  la  communication  avec  les  systAmes 
da  detection  et  de  contrAle  (radars), 
ces  systAmes  pouvant  Atre  terrestres 
ou  aAriens,  statiques  ou  mobiles. 

Au  niveau  des  moyens  de  dAveloppement,  le 
logiciel  ^oue  un  rdle  de  plus  en  plus 
important.  II  complete  les  techniques  da 
1' automatique  principalement  utilisAes 
pour  les  systAmes  de  pilotage  et  guidage. 

Si,,  aujourd'hui,  les  langages  de  prograra- 
mation  de  type  ADA  ainsi  que  les  mAthodes 
de  specification  et  de  conception  sont 
couramment  mis  en  oeuvre,  les  technologies 
du  logiciel  ne  cessent  d'Avoluer  :  les 
langages  orientAs  objets  et  les  systAmes 
experts  actuellement  utilises  en  phase 
d' etude  feront  bientdt  partie  des  techno¬ 
logies  embarquees.. 

Le  rythme  important  avec  lequel  ces  evolu¬ 
tions  fonctionnelles  et  techniques  sont 
menAes  nAcessite  de  mettre  en  place  des 
moyens  pour  maltriser  et  anticiper  ces 
evolutions.  Au  niveau  de  la  definition  des 
fonctionnalites,  ceci  se  traduit  par  un 
renforcement  du  dialogue  que  SEXTANT 
entretient  avec  ses  diffArents  interlocu- 
teurs  :  les  corapagnies  aAriennes,  les 


pilotes  et  les  avionneurs.  Des  mAthodes 
accompagnAes  d'outils  supports  sont  mises 
en  place  pour  formaliser  ces  dialogues 
afin  d'aboutir  A  des  expressions  de  besoin 
completes  et  non  ambigues. 

Le  dApartement  Avant-Pro jets  de  la 
Division  Conduite  du  Vol  est  responsable 
de  la  definition  des  moyens  de  specifica¬ 
tion  fonctionnelle  utilisAs  dans  les 
phases  amont  du  cycle  de  dAveloppement  : 
ces  phases  sont  d'autant  plus  importantes 
qu'une  erreur  introduite  A  ce  stade  est 
amplifiAe  au  cours  des  phases  aval  et  que 
sa  dAcouverte  tardive  entralne  des  retours 
en  arriAre  toujours  trAs  coQteux. 

Ce  document  prAsente  les  diffArents 
besoins  qui  apparaissent  dans  ces  phases 
amont  ainsi  que  les  divers  environnements 
mis  en  place  A  SEXTANT  Avionique  pour  la 
specification  et  le  maquettage  des  logi- 
ciels  da  gestion  du  vol. 


2.  hut  besoins  en  moyens  de  spAoiflcatlon 

Les  besoins  sont  issus  du  constat  d'une 
contradiction  concernant  les  documents  de 
specification  : 

-  ils  constituent  les  premiers  documents 
contractueis  d'un  projet  et  figurent 
de  ce  fait  parmi  les  documents  les 
plus  importants, 

-  leur  forme,  des  documents  papier  com¬ 
poses  d'un  grand  nombre  de  pages  avec 
des  references  croisAes  non  structu- 
rAes,  rend  problAmatique  voire  parfois 
impossible  leur  exploitation. 

Ainsi,  les  outils  d'aide  A  la  phase  de 
specification  doivent  non  seulement  per- 
raettre  d' exprimer  aisAment  les  exigences 
fonctionnelles,  mais  aussi  de  vArifier 
rapidement  et  A  posteriori  la  validitA  des 
documents  de  specification  par  rapport  A 
ces  mAmes  exigences. 

La  solution  consiste  A  mettre  en  oeuvre 
des  moyens  de  specification  formelle  : 
leur  caractAre  formel,  par  opposition  au 
caractAre  informel  inherent  aux  langages 
naturels  souvent  sujets  A  interpretation, 
Avite  les  ambiguitAs  et  les  incomplAtudes . 
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Ceci  est  parfois  obtenu  au  detriment  de  la 
lisibilitfe  des  ap^ciflcatlons.  One  solu¬ 
tion  complete  consiste  alors  associer 
une  activit6  de  maquettage  A  I'utilisation 
de  m6thodes  de  specification  formelle.  II 
devient  ainsi  possible  do  valider  tr^s  tdt 
dans  le  cycle  de  d6veloppement  1' expres¬ 
sion  des  besoins,  la  phase  integr^e  de 
spfeoification/maquettage  apportant  le 
double  avantage  : 

-  de  mettre  A  la  disposition  des  clients 
un  document  sans  ambiguite  ni  incom- 
pietude  et  des  moyens  permettant  une 
exploitation  rapide  et  lisible, 

-  de  mettre  4  la  disposition  des  r6ali- 
sateurs,  une  expression  des  besoins 
claire  et  complete  pour  les  functions 
4  r4aliser  ;  le  caract4re  formel  des 
specifications  permet  de  mettre  en 
place  les  moyens  d' assurer  la  tragabi- 
lite  avec  la  phase  de  conception  logi- 
cielle  et,  lorsque  cela  est  possible, 
avec  la  phase  de  generation  automa- 
tique  do  code  embarqu6  [13]. 

2.1.  Integration  da  la  apedf Icatlon  at  du 
maquattago  au  aain  d'un  mema  anvlronnainant 

SEXTANT  Avionique,  considerant  specifi¬ 
cation  et  maquettage  comme  indissociables, 
a  mis  en  place  plusieurs  environnements, 
chacun  base  sur  une  methode  da  specifica¬ 
tion  particuliAre  4  laquelle  est  associe 
un  gen6rateur  da  code.  La  simulation  obto- 
nue  par  1' execution  du  code  g6nere  so  fait 
dans  le  cadre  d'un  environnement  de 
maquettage  pr6-existant .  Lea  fonctionnali- 
tes  communes  4  ces  environnements  de  spe¬ 
cif  ication/maquettage  iont  decrites  dans 
la  suite  de  ce  document. 


2 . 1 . 1 . Specif loation  at  "verifications  sta- 
tiquas" 

A  une  methode  de  specification  formelle, 
sent  associees  deux  notations  strictement 
equivdlentes  :  la  premiere  est  graphique 
et  forme  1' interface  dont  le  specifieur 
dispose  pour  exprimer  ses  besoins.  La 
seconde  est  textuelle  et  constitue  le  lan- 
gage  intermediaire  4  partir  duquel  les 
verifications  liees  4  la  methode  sont 
faites . 

Ces  verifications  sont  au  nombre  de  deux  : 
la  premiAre,  purement  syntaxique,  venfie 
que  tous  les  symbolos  utilises  par  le  spe¬ 
cifieur  pour  sa  description  formelle  sont 
autorises  et  que  leur  agencement  les  uns 
avec  1<  ■  autres  correspond  4  la  gramraaire 
du  langage.  Cette  verification  eat  facili- 
tee  lorsqu'4  partir  de  la  saisie  effectuee 
4  i'aide  d'un  6diteur  graphique  d6di6,  la 
representation  equivalente  dans  le  langage 


intermediaire  est  automatiquement  g6n6ree. 

La  seconde  verifie  qu'il  n'y  a  pas  d' inco¬ 
herence  au  niveau  de  la  semantique  de  la 
methode  :  par  example,  des  cas  de  division 
par  zero  et  les  conflits  de  types  peuvent 
Stre  detectes  lors  d'une  phase  d' analyse 
semantique.  La  mise  en  evidence  de  ces 
incoherences,  dont  1' implementation  pent 
etre  trAs  complexe,  est  faite  de  maniere 
dynamique,  e'est  4  dire  lore  de  I'execi- 
tion  du  code  maquette. 

2. 1.2. Maquettage  et  "verifications  dyna- 
miquet" 

2. 1.2.1. Mise  au  point  da  la  specification 

L'animation  ou  la  simulation  d'une  des¬ 
cription  formelle  des  specifications  a 
pour  but  de  les  valider.  Cette  phase  de 
validation  consiste  4  : 

-  verifier  que  la  description  est  non 
ambigue  et  complete  :  e'est  ce  qu'on 
appelle  "le  debuggage  de  la  specifica¬ 
tion"  qui  consist®  4  detecter  les 
erreurs  dues  au  non  respect  de  la 
methods  et  qui  n' ont  pas  pu  6tre 
deoouvertes  lors  des  verifications 
statiques, 

-  verifier  que  la  description  formelle 
oxprime  bien  les  besoins  et  que  tous 
les  besoins  y  sont  exprim6s  :  e'est  ce 
qu'on  appelle  la  "validation  de  la 
specification" . 

Dans  les  deux  cas,  le  specifieur  est  amend 
4  modifier  la  description  formelle  si 
1' execution  du  code  maquette  associd  ne 
correspond  pas  4  ce  qu'il  attend,  que  ce 
sort  du  point  de  vue  "debuggage"  ou  du 
point  de  vue  "validation". 

Pour  faciliter  la  detection  des  erreurs, 
difldrents  modes  d' execution  du  code 
maquette  sont  impiementes  :  plusieurs 
modes  "pas  4  pas"  (avec  differentes 
valeurs  du  pas)  et  un  mode  en  continu  avec 
possibilite  d'arrSt  sur  dvenement. 

Pour  faciliter  la  correction  des  erreurs 
dans  la  description  formelle,  la  tragabi- 
lite  est  assurde  entre  les  dldments  de 
specification  et  le  code  maquette. 

2. 1.2. 2. Interface  da  simulation 

L' interface  de  simulation  constitue  le 
moyen  de  dialogue  entre  1' environnement  de 
spdcif ication/maquettage  et  le  spdcifieur. 

Outre  les  moyens  d' edition  ndcessaires  4 
la  formulation  des  exigences  fonction- 
nelles,  le  spdcifieur  dispose  de  moyens 
lui  perr  tant  de  contrdler  sa  simulation; 


7-3 


-  en  envoyant  aussi  bien  des  atimuli 
(Run,  Stop...)  que  dea  donn^ea, 

-  en  viaualiaant  dea  informationa  au 
cours  d'une  aimulation. 

Cea  moyena  aont  baa^a  aur  lea  rea- 
aourcea  qu' off rent  aujourd'hui  lea 
atations  de  travail,  en  particulier 
I'utiliaation  de  la  aouria,  du  multi- 
fenetrage. . .  (Cf ..  annexe  3)  . 

La  caract^rlatique  prlncipale  de 
1' interface  de  aimulation  eat  d'etre 
compl^tement  diaaociie  de  la  deacrip- 
tion  formelle.  Pour  chaque  deacrip- 
tion  on  peut  difinir  pluaieura  inter- 
facea  poaaiblea  grSce  k  un  langage  de 
definition  d' interface ., 

2. 2. Integration  da  pluslaurs  anvlronna- 
manta  da  apAciflcatlon/maquattaga  au  tain 
d'un  atallar 

2 . 2 . 1 .Petition  du  probiema 

La  multiplication  d' environnementa  dMiia 
e  dea  metiera  tree  apecialiaea,  toua  uti- 
liafea  pour  la  developpement  d'un  mime  aya- 
t6me  de  Geation  du  Vol,  n6ceaaita  d'int6- 
grer  eej  environnementa  entra  eux. 


Dea  environnementa  de  apedfication/ 
maquettage  i  vocation  “generaliate"  peu- 
vent  aider  k  la  formaliaation  d'un  metier 
particulier  :  ainai,  I'environnement 
OOA/KEE  a  permia  de  developper  un  environ- 
nement  de  apecification/maquettage  d'une 
application  ELS  (cf.  troisieme  partie  de 
ce  document) . 

2 . 2 . 2 . Structure  d'accuail 

Lea  problAmea  d' integration  ae  poaent  k 
pluaieura  niveaux  : 

-  integration  1  un  environnement  d'une 
nouvelle  methode  de  apecification, 

-  integration  A  un  environnement  d'une 
nouvelle  teclinique  de  maquettage, 

-  integration  de  pluaieura  environne¬ 
menta  da  apAcif ication/maquettage  lea 
una  avec  lea  autrea  :  pour  dea  mSmea 
environnementa,  1' integration  peut 
etre  faite  de  diffArentea  maniArea,  en 
fonction  du  mode  de  fonctionnement  du 
pro jet,  de  la  repartition  dea  tSchea 
entre  lea  diffArenta  intervenanta. . . 

La  aolution  conaiate  A  diapoaer  d'une 
atructure  d'accueil  conatituAe  de  mAthcdea 
et  d'outila  permettant  de  apecifier  lea 
differenta  impAratifa  d' integration. 


Un  environnement  donnA,  conatituA  d'une 
mAthode  de  apAcif ication  et  d'un  environ¬ 
nement  de  maquettage,  eat 

-  aoit  dediA  A  un  mAtier  particulier 
parmi  leaquela  on  peut  citer  celui  dea 
loia  de  pilotage,  de  la  logique  du 
dialogue  horame-maohine, 

-  aoit  A  vocation  plua  g6n6rale. 

Chacun  dea  mAtiera  mia  en  oeuvre  pour  le 
dAvelopperaent  dea  fonctiona  de  Geation  du 
Vol  dolt  faire  face  A  une  double  evolu¬ 
tion: 

-  du  point  de  vue  dea  moyena  de  apAcifi- 
cation  aaaociAa,  comme  par  example 
I'apparition  de  nouvellea  mAthodea, 
lea  adaptationa  A  apporter  A  1' inter¬ 
face  homme-machine  dea  outila  aup- 
porta,, 

-  et  du  point  de  vue  dea  domainea 

d' intervention  dea  mAtiera  qui  aont  do 
plua  en  plua  nombreux  au  fur  et  A 
meaure  de  I'apparition  de  nouvellea 
fonctionnalitAa  dana  lea  fonctiona  de 
Geation  du  Vol. 


Cette  atructure  d'accueil  doit  diapoaer  de 
troia  typea  d'outila  : 

-  outila  de  definition  de  1' integration 
de  pluaieura  mAthodea  entre  ellea,, 

-  outila  de  definition  de  1' integration 
dea  techniquea  de  maquettage  entre 
ellea, 

-  outila  de  definition  de  1' integration 
d'une  mAthode  avec  une  technique  de 
maquettage. 


} 

} 
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-  Structuration  en  couches  de  la  structure 
d'accueil  - 


D' autre  part,  ces  nouvelles  fonctionnali- 
t6s  g6n^rent  de  nouveaux  metiers  et  n6ces- 
sitent  un  environnement  de 
sp6cif ication/maquettage  adapts  :  tel  est 
le  cas  pour  I'ELS  dont  la  mattrise  demande 
la  mvse  en  oeuvre  de  techniques  de  type 
"Hypertext"  non  utilis^es  ^usqu'alors  pour 
le  d^veloppement  des  systdmes  einbarqu^s. 


A  partir  de  d6£initions  Rentes  avec  ces 
outils,  la  structure  d'accueil  impl6mente, 
sans  aucune  intervention  humaine  suppl^- 
mentaire,  un  nouvel  environnement  int^gr^ 
de  specif ication/maquettage  adaptit. 
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3.  Validations 

Deux  environnements  de 
sp6cif ication/maquettage,  destines  A  la 
formalisation  des  "fonctions  nouvelles", 
ont  6t6  mis  en  place  au  sein  du 
DApartement  Avant-Pro;)ets  de  la  Division 
Conduite  du  Vol  :  le  premier  est  bas6  sur 
la  mAthode  SART  (Structured  Analysis  & 

Real  Time)  pour  la  specification  fonction- 
nelle  et  le  langage  ADA  pour  le  maquetta- 
ge Le  second,  gui  s'appuie  sur  les  lan~ 
gages  orientfes  ob]ets,  a  servi  4  formali- 
ser  la  fonction  ELS  (Electronic  Library 
System)  et  a  conduit  4  la  mise  on  place 
d'un  environnement  de 

sp6cification/maquettage  d6di6  4  ce  type 
d' application. 

3.1.Dn  anvironnamant  "elaisiqua" :  SART/ADA 
3.1.1.1a  mAthoda  SART  considArAa 

La  mAthodo  SART  eat  particulierament 
adaptAe  4  la  specification  fonctionnelle 
des  applications  temps-rAel.  L'outil  STP 
(Software  Through  Pictures)  [1],  un  des 
outils  du  marche  supportant  la  mAthode 
SART,,  est  largement  diffuse  4  SEXTANT  pour 
la  specification  des  fonctions  assurAes 
par  lea  systAmes  de  Conduite  du  Vol. 

Le  terme  "SART"  est  genArique  et  dAsigne 
en  fait  deux  mAthodes  particuliAres,  celle 
de  "Ward  A  Mellor"  (3)  et  celle  de 
"Hatley"  [4).  La  mAthodo  SART  est  semi- 
formelle  car  certaines  combinaisons  syn- 
taxiques  n'ont  pas  une  sAmantiquo  suffi- 
samment  prAcise.  La  mAthode  considArAe  ici 
est  une  extension  formelle  4  celle  de 
"Ward  A  Mellor"  :  les  ambiguitAs  sAman- 
tiques  ont  AtA  supprimAes. 

3.1.1.1.Ii«  modAle  des  traitenents  SA 

Le  prinoipe  de  SART  consiste  4  dAcrire 
les  fonctions  assurAea  par  un  logiciel 
sous  la  forme  d'une  dAcomposition  hiArar- 
chique  descendante,  suivant  le  principe 
d' Analyse  StructurAe  de  YOURDON/DEMARCO 
[2] .  Chaque  niveau  de  description  est  com- 
plet  en  lui-mAme,  mais  la  prAcision  crolt 
avec  la  profondeur. 

Une  description  SART  est  constituAe  d'une 
arborescence  de  diagramraes,  la  racine 
Atant  un  diagramme  de  contexte  et  les 
autres  noeuds  des  diagrammes  de  flux  de 
donnAes  (DFD) .  Chaque  diagramme  contient 
des  AlAments  de  type  :  FONCTION,  PSPEC, 
CSPEC,  DATA-STORE,  ENTITE-EXTERNE  et 
CONNEXION.  Seuls  les  AlAments  de  type 
FONCTION  se  dAcomposent  en  un  diagramme 
fils.  Chacun  de  ces  AlAments  possAde  des 
flux  entrants  et  des  flux  sortants,  ces 


flux  assurant  la  connectique  d'un  modAle 
SART. 

Deux  types  de  flux  sont  dAfinis  :  les  flux 
de  donnAes  et  les  flux  de  contrAles  (ou 
AvAnements)  .■  La  diffArence  se  situe  au 
niveau  de  la  perception  de  ces  flux  par 
les  AlAments  qui  les  regoivent  :  les  flux 
de  contrAle  sont  pergus  immAdiatement  par 
I'AlAment  receveur  oar  son  oomportement 
est  susceptible  d'Atre  modifiA  immAdiate¬ 
ment  alors  que  les  flux  de  donnAes  sont 
considArAs  comma  de  simples  supports  de 
donnAes,  donnAes  que  I'AlAment  receveur 
peut  aller  chercher  de  lui-mAme  et  quand 
il  le  dAcide. 


3. 1.1. 2.  Le  modAle  des  contrAles  :  RT 

Si  le  modAle  des  traitements  dAcrit  de 
maniAre  statique  le  logiciel  4  rAaliser, 
sous  la  forme  de  fonctions  s'Achangeant 
des  donnAes,  le  modAle  des  contrdles 
dAcrit  la  dynamique  de  ces  fonctions  les 
unes  par  rapport  aux  autres.  Les  dia¬ 
grammes  Atats/transitions  associAs  4 
chaque  CSPEC  et  les  flux  de  contrAle 
entrant  at  sortant  de  ces  CSPEC  permettent 
de  dAcrire  cette  logique. 

Chaque  DFD  d'une  spAoif ication  SART  dAcrit 
un  AlAment  FONCTION  d'un  diagramme  de 
niveau  supArieur.  La  CSPEC  est  introduite 
sur  un  DFD  pour  dAcrire  comment  la  fonc¬ 
tion  mAre  du  DFD  prend  en  compte  les  flux 
de  contrdle  qu'elle  pergoit  et  comment 
elle  Amet  les  flux  de  contrdle  sortants  : 


La  CSPEC  C  permet  de  dAcrire  les  change- 
raents  de  comportement  de  la  fonction  B  4 
partir  non  seulement  des  AvAnements 
externes  el  et  e2  mais  aussi  des  AvAne¬ 
ments  internes  (venant  de  B.2  ou  Amis  vers 
B.l).  Les  changements  de  comportement  de  B 
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correspondent  en  fait  i  des  changements  de 
comportement  des  sous-fonctions  B.l,  B.2 
et  &.3.-  Via  la  CSPEC  C,  un  diagramme 
fetats/transitions  est  associ6  4  la  fonc- 
tion  B.  II  est  tel  que 

-  1' ensemble  des  6tats  correspond  a  un 
ensemble  de  configurations  diffferentes 
des  sous-fonctions  B.l,_  B,2  et  B.3,, 

-  1' ensemble  des  6v6nements  conditions 
de  transition  est  constitufe  par  les 
flux  de  contrdle  entrant  dans  la  CSPEC 
:  ces  6v6nements  sont  sort  externes 
(el  )  sort  internes  (venant  de  B.2), 

-  1' ensemble  des  6v4nement3  4mis  lors 
des  transitions  est  oonstitu6  par  les 
flux  de  contrdle  sortant  de  la  CSPEC  : 
ces  6vfenements  sont  soit  externes  (e2) 
soit  internes  (6mi3  vers  B.l). 

3.1.2.1a  traductaur  SART/XDA 

Les  motivations  qui  ont  conduit  au  choix 
de  ADA  comme  langage  cible  sont  au  nombre 
de  trois  : 

•  les  concepts  du  parallAlisme  mis  en 
oeuvre  dans  ADA  (notion  de  t4c)io,  ren- 
dei-vous)  ont  permis  d' implAmenter  un 
module  SART  comme  un  ensemble  de  pro¬ 
cessus  en  parallAle  s'Achangeant  des 
donnAes  et  se  synchronisant . 

•  le  concept  de  gAnAricitA  perraet  de 
dAfinit,  pour  cheque  type  d'AlAment  de 
la  mAthode  SART,  un  package  gAnArique 
que  le  gAnArateur  de  code  instancie 
pour  chaque  AlAraent  de  chacun  des  dia- 
grammes  d'une  spAcification  SART. 

Certains  paramAtres  sont  communs  A 
tous  lea  packages  gAnAriques  (par 
example,  la  liste  des  flux  sortants) . 
D'autres  ont  des  paramAtres  particu- 
liers  dApendant  du  type  de  I'AlAment 
SART  (par  example,  le  package  corros- 
pondant  A  I'AlAment  de  type  CSPEC  a  un 
paramAtre  "automate") . 

En  annexe  1,  est  ]ointe  la  partie  spA¬ 
cification  des  SIX  packages  gAnA¬ 
riques.  En  particulier,  pour  le  packa¬ 
ge  correspondant  aux  AlAments  de  type 
PSPEC,  cinq  tAchos  sont  gAnArAes  pour 
implAmenter  les  deux  types  de  flux  : 
les  flux  de  oontrdle  sont  percus  immA- 
diatement  par  la  PSPEC  alors  que  la 
consommation  d'un  flux  de  donnAes  est 
coraplAtement  dAsynchronisAe  de  sa  pro¬ 
duction.  La  communication  entre  ces 
cinq  t Aches,  dAcrite  dans  le  formalis- 
me  HOOD  [7],  est  ]ointe  en  annexe  2. 

’  le  choix  de  ADA  comme  langage  de 
maquettage  permet  d'envisager  une 
rAutilisation  partielle  du  code  de 
maquettage  dans  la  phase  de  codage  ; 


le  code  rAcupArable  se  situe  au  niveau 
de  la  description  des  PSPEC  faite  dans 
un  pseudo-langage  de  type  ADA., 

3.1.3.1'anTironnainant  de  simulation  mini¬ 
mal 

Dans  un  modAle  SART,  la  description  du 
dialogue  entre  la  fonction  spAcifiAe  et 
son  environnement  est  entiArement  regrou- 
pAe  dans  le  diagramme  de  contexts  :  on  y 
prAcise  les  flux  de  donnAes  et  les  flux  de 
contrAles  AchangAs  entre  les  entitAs 
externes  et  la  fonction  que  I'on  spAcifie. 

L' idAe  de  dApart  est  de  considArer  que  les 
entitAs  externes  sont  elles-mAmes  issues 
d'une  SpAcification  SART.  Ceci  permet  de 
considArer  1' environnement  de  maquettage 
comme  pouvant  Atre  enrichi  A  chaque  fois 
qu'une  nouvelle  fonction  est  spAcifiAe  en 
SART,  celle-ci  devenant  une  entitA  externe 
utilisable  pour  la  spAcification  d'une 
autre  fonction. 

Au  dApart,  c'est  A  dire  avant  de  disposer 
d' entitAs  externes  issues  de  spAcifica- 
tions  SART,,  on  dispose  d'un  environnement 
minimal  de  simulation  constituA  d'un 
ensemble  d' entitAs  externes  de  base  A  par- 
tir  desquellos  on  peut  en  construire  de 
nouvelles  qui,,  elles,  seront  issues  de 
maniAre  automatique  d'une  spAcification 
SART.  Ces  entitAs  externes  de  base  sont 
aussi  bien  de  haut  niveau  et  dApendent 
alors  d'une  application  (par  exemple 
"Guidage",,  "Pilote",  "ParamAtres  avion", 
"Plan  de  vol"  et  "MCDU"  pour  la  gestion  du 
vol)  que  plus  gAnArales  comme  par  exemple 
"clavier",  "visu",  "fichier"  et  destinAes 
A  plusieurs  types  d' application. 


3.1.4.Knvironn«mant  da  simulation  Atendu 

L' environnement  de  simulation,  utilisA 
pour  valider  la  spAcification,  propose 
deux  modes  d'exAcution  : 

-  un  mode  "pas  A  pas"  oA  la  valeur  du 
pas  correspond  A  1' Amission  d'un  flux 
de  contr&le  par  un  des  AlAments  de  la 
spAcification, 

-  et  un  mode  en  continu  avec  possibilitA 
d'arrAt  pour  observer  et  inspecter 
I'Atat  de  la  simulation. 

L'  Atat  de  la  simulation  correspond  aux 
Atats  des  diffArents  AlAments  du  modAle 
SART  ! 

-  I'Atat  des  PSPEC  et  des  FONCTIONS  : 
actif  ou  inactif, 

-  I'Atat  courant  de  chaque  diagramme 
Atats /transitions, 

-  la  production  et/ou  la  consommation 
des  flux  de  donnAes, 
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-  1' Emission  des  flux  de  contrdle., 

L' acc6s  i  toutes  oes  informations  est  pos¬ 
sible  grace  k  une  instrumentation  du  code 
g6n6r6  par  du  code  permettant  de  garder,  4 
tout  moment,  la  tragabilitfe  entre  la  simu¬ 
lation  et  la  specification  SART.- 

One  extension  pr^vue  4  cet  environnement 
est  son  integration  avec  1' environnement 
de  specif ication/maquettage  dedie  aux  lois 
de  pilotage  (VISA)  :  un  type  d' integration 
possible  consiste  4  decrire  les  PSPECS  non 
plus  directement  par  une  procedure  ADA 
mais  avec  le  formalisms  de  la  methods  de 
specification  des  lois  de  pilotage  :  ceci 
est  d'autant  plus  facile  que  VISA  permet 
la  generation  de  code  ADA. 

D'autres  extensions  sont  4  1' etude  : 

-  prendre  en  corapte  les  particularites 
de  la  methode  de  HATLEY^  en  particu- 
lier  les  tables  d' activation/desacti- 
vation  et  les  tables  de  decision,, 

-  enrichir  le  models  des  contr61es  par 
des  langages  formels  de  type 
Statecharts  [8]  et  HMS  (9], 

-  et  le  couplage  avec  1 ' environnement  4 
vocation  "fonction  nouvelle"  OOA/KEE. 


3. 2. On  environnement  "evance"  OOA/KJEE 

L'approche  fonctionnelle  en  phase  de 
specification  consiste  4  decrire  le  syste¬ 
ms  4  r6aliser  en  listant  les  fonctions 
qu'il  doit  assurer  et  les  flux  d' informa¬ 
tion  qu'elles  s'6changent.  Cette  approche 
fonctionnelle  descendants  est  naturelle  en 
phase  de  specification  et  correspond  aux 
habitudes  des  specif leurs.  L' approche 
ob]et,  qui  favorise  la  r6utilisation  et  la 
fiabilite  du  logiciel,  est  une  approche 
ascendante  plut6t  utilises  en  phase  de 
conception.  Lorsque  les  approches  fonc- 
tionnelle  et  ob]et  sont  retenues  respecti- 
veraent  en  phase  de  specification  et  en 
phase  de  conception,  un  problems  de  tran¬ 
sition  apparalt  entre  cos  deux  phases. 

Pour  eviter  cet  inconvenient,  SEXTANT 
Avionique  a  expenmente  I'utilisation  de 
I'appioohe  objet  dAs  la  phase  de  specifi¬ 
cation  dans  le  cadre  de  certains  projets 
de  conduits  du  vol.  Les  rAsultats  obtenus 
s'avArent  prometteurs  :  les  specif leurs  se 
sont  trAs  vite  adaptAs  et  ont  6te  trAs 
enthousiastes .  Un  environnement  de  spAci- 
f ication/maquettage  basA  sur  I'approche 
ob3et  a  done  AtA  mis  en  place  pour  alder  4 
la  formalisation  de  certaines  des  nou- 
velles  fonctions  de  gestion  du  vol. 


3. 2.1.  La  mAthoda  OOA  considArAa 

Une  methode  de  specification  dAcrit 
aussi  bien  1' aspect  statique  que  dynamique 
d'un  logiciel.  La  mAthode  considArAe  ici 
est  inspires  des  travaux  raenAs  par  Goad  et 
Yourdon  (5)  ainsi  que  par  Schlaer  et 
Mellor  [10)  pour  dAfinir  une  approche 
objet  dans  les  phases  amont  du  cycle  de 
dAveloppement . 

Les  concepts  de  base  mis  en  oeuvre  dans 
ces  mAthodes  sont  ceux  des  Langages 
OrientAs  Objets  (LOO)  dont  le  plus 
illustre  est  SMALLTALK. 

3.2.1.1. Aspacts  statiquaa 

La  stratAgie  de  description  des  aspects 
statiques  est  issue  de  la  mAthode  OOA 
(Object  Oriented  Analysis)  (5) .  La  stratA- 
gie  globale  de  modAlisation  a  Ate  simpli¬ 
fies  en  ne  retenant  que  quatre  des  princi- 
paux  concepts  de  la  mAthode  OOA  :  il 
s'agit  des  concepts  de  CLASSE  (identique  4 
celui  des  LOO  [11)),  de  STRUCTURE  D' ASSEM¬ 
BLAGE,  de  GENERALISATION/SPECIALISATION  et 
de  LIEN  D' INSTANCES. 

3.2.1.1.1. Clas«a 

Une  classe  est  un  type  abstrait  de  don- 
nAe  dAfini  par  une  lists  d'attributs  et  de 
services  (ou  mAthodes)  caractAristiques  de 
ses  iLstancea  : 


slaaafi.  PLAN-DE-VOL  : 
attributs  :•  aAroport  de  depart 
aAroport  d'arrivAe 
liste  ordonnAe  de  p.ints  do 
passage 

ins6rer-point-de-passage 
(point_precedent, nouveau_point) 
activer 


-Definition  de  la  classe  des  plans  de  vol- 


L' instance  PARIS-ATHENES  de  la  classe 
PLAN-DE-VOL  associe  des  valeurs  particu- 
liAres  aux  attributs  : 


instance  PARIS-ATHENES  classe-me re  PLAN- 
DE-VOL  : 

aAroport  de  depart 

-  PARIS 
aAroport  d'arrivAe 

-  ATHENES 

liste  ordonnAe  de  points  de  passage 

-  (BERNE  MILAN  BARI) 
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fin  instance 


-  Definition  de  1' instance  PARIS-ATHENES  - 

Cheque  instance  est  susceptible  de  rendre 
les  services  d6£inls  dans  la  classe  mAxe 
aux  autres  instances.  Par  example,  si  le 
pilote  sollicite  le  service  "insArer- 
point-de-passage (MILAN, ROME) "  au  plan  de 
vol  PARIS-ATHENES,  son  attribut  "liste 
ordonn6e  da  points  do  passage"  sera  modi- 
fie  de  la  facon  suivante  : 


instance  PARIS-ATHENES  classe-mere  PLAN- 
DE-VOL  : 

aeroport  de  depart 

-  PARIS 

aeroport  d'arrivee 

-  ATHENES 

liste  ordonnee  de  points  de  passage 

-  (BERNE  MILAN  ROME  BARI) 


3. 2. 1.1. 2. Lien  d' instances 

Le  concept  de  lien  d' instances  (ou  rela¬ 
tion)  s' inspire  des  modAles  ralationnels 
binaires  de  description  des  donnAes  (mode- 
le  entite-association  en  particulier)  uti¬ 
lises  pour  definir  les  schemas  conceptuels 
des  bases  de  donnees  (12). 

On  lien  entre  deux  classes  d'objets  est 
unidirectionnel  et  met  en  relation  une 
instance  de  la  classe  de  depart  avec  une 
ou  plusieurs  instances  de  la  classe 
d'arrivee,  ce  nombre  etant  defini  par  la 
cardinalite  associee  au  lien  par  un  couple 
de  valeurs  :  (cardinalite  minimum,  cardi- 
nalite  maximum) . 

Plusieurs  types  do  relation  existent  : 

-  la  relation  "est  compose  do", 

-  la  relation  "eat  compose  d'une  collec¬ 
tion  de", 

-  la  relation  "est  compose  d'une  liste 
ordonnee  de", 

-  et  les  relations  definies  par  le  spe- 
cifieur. 


Sur  le  schema,  chaque  instance  de  la  clas¬ 
se  AVION  est  composes  d'une  collection 
d' instances  de  la  classe  TRAJECTOIRE, 
cette  collection  peut  6tre  vide  (la  cardi¬ 
nalite  minimum  est  nulle)  ou  contenir  un 
nombre  non  borne  d' instances  (la  cardina¬ 
lite  maximum  est  "m") .  De  la  m6me  maniAre, 
chaque  instance  de  la  classe  CONSIGNE  est 
composes  d'une  liste  ordonnee  d' instances 
de  la  classe  ORDRE-GOUVERNES,  cette  liste 
doit  contenir  au  moins  une  instance  (la 
cardinalite  minimum  est  egale  A  1) . 

Chaque  instance  de  la  classe  AVION  est,  A 
tout  moment,  en  relation  avec  0  ou  1  ins¬ 
tance  de  la  classe  PLAN-DE-VOL,  la  rela¬ 
tion  "plan-de-vol-acti£"  a  ete  definie  par 
le  specifieur. 

3, 2. 1.1. 3. Structure  a' assemblage 

Le  concept  de  structure  d' assemblage 
permet  de  defirir  des  classes  d'objets 
comme  des  n-uplets  d' autres  classes  :  il 
se  rapproche  de  la  notion  "d' enregistre- 
ment"  que  I'on  trouve  dans  les  langages  de 
programmation  structurAe  tels  que  PASCAL 
et  ADA.  Pour  illustrer  I'emploi  de  ce 
concept,  supposons  que  la  classe  TRAJEC¬ 
TOIRE  est  entiArement  dAfinie  par  le 
simple  fait  que  chaque  instance  est  compo- 
sAe  d'une  CONSIGNE  et  d'un  PLAN-DE-VOL.  La 
classe  TRAJECTOIRE  ne  dispose  done  pas 
d' attribute  et  de  services  propres  et  la 
notation  associAe  A  la  classe  TRAJECTOIRE 
devient  : 


-  Liens  d' instances  entre  structure 
d' assemblage  et  classes  - 

3 . 2 . 1 . 1 . 4 . GAnAralisation/spAclalleation 


Ce  concept  est  en  fait  une  autre  forma¬ 
lisation  du  concept  d'hAritage  (simple  et 
multiple)  des  LOO.  II  a  I'avantage  de  sim¬ 
plifier  le  graphs  d'hAritage  en  ne  faisant 
apparaitre  que  les  classes  AlAmentaires. 

Ce  sont  les  cardinalitAs  associAes  aux 
noeuds  du  graphe  qui  dAfinissent  les  sous- 
classes  obtenues  par  hAritage  des  classes 
AlAmentaires  et  leur  caractAre  d'lnstan- 
ciabilitA  (le  fait  qu'une  classe  peut  ou 
ne  peut  pas  avoir  des  instances  dans  le 
"monde  rAel",  e'est  A  dire  celui  qui 
concerns  le  spAcifieur)  : 
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-Graphe  de  g6n6rali3ation/sp6ciali33tion- 

La  lecture  de  ce  graphe  permet  de  d4durre 
les  assertions  suivantes  : 

-  Les  classes  "avion-militaire",  "avion- 
oivil",,  "jet"  et  "avion-A-propulsion" 
h6ritent  des  caraot6ristiques  (attri- 
buts  et  services)  de  la  classe 
"avion". 

-  Les  oardinalit6s  expriment  las  heri¬ 
tages  multiples  ainsi  que  les  classes 
instanciables .  Lo  graphe  d' heritage 
equivalent  dans  le  formalisme  habituel 
serait  le  suivant  (les  classes  instan- 
oiables  apparaissent  en  grise)  : 


3. 2. 1.2. Aspects  dynamiquas 

La  strat6gie  de  description  des  aspects 
dynandques  est  issue  de  la  methode  OOSA 
(Object  Oriented  Systems  Analysis)  [10] . 

11  s'agit  d'associer  A  chaque  classe 
d'objets  un  diagramrae  etats/transitions 
dAcrivant  le  "cycle  de  vie"  des  instances. 

Co  diagramme  dAcrit  la  logique  d' envoi  de 
messages  entre  objets  en  fonction  des 
changements  de  valeur  des  attributs. 

La  sollicitation  d'un  service  d'un  objet 
receveur  par  un  objet  demandeui;  s'appelle 
"1' envoi  de  message"..  Deux  types  de  solli- 
citations  sont  possibles  :  le  premier  est 
bloquant,  1' objet  demandeur  se  bloque 
jusqu'A  CO  que  lo  service  ait  6t6  complA- 
tement  rendu  (envoi  de  message  synchrone) ,, 
le  second  permet  4  1' objet  demandeur  de 
solliciter  un  service  d'un  autre  objet 
sans  attendre  qu'il  ait  6t6  rendu  (envoi 
do  message  asynchrone) . 


La  logique  de  d6clenohement  des  services,, 
dAcrite  par  les  diagrammes  Atats/transi- 
tions,  est  spAcifieo  au  niveau  des  classes 
:  les  sous-classes  et  les  instances  hAri- 
tent  de  cette  dynamique  et  en  particulier 
en  cas  d'h6ritage  multiple,  la  sous-classe 
hArite  do  ohacun  des  diagrammes  des 
classes  mAres. 


3.2.2.LH  traductaur  OOA/KEE 


-  Graphe  d'liAritago  equivalent  au  graphe 
de  gAneralisation/speoialisation  - 


La  cardinalite  (1,2)  permet  do  faire 
remonter  au  niveau  du  noeud  pAro 
(celui  qui  porto  la  cardinalitA 
(2,2)),  les  classes  "avion-militaire",, 
"avion-civil"  et  la  classe  composAe 
"avion-militaiio-civil".  Si  cette  car- 
dinalite  avait  AtA  (1,1),  les  classes 
remontAes  se  .seraient  limitAes  aux 
classes  "avion-civil"  et  "avion-mili- 
taire"  :  un  avion  n'aurait  pas  pu 
avoir  4  la  fois  les  caractAristiques 
d'un  iivion  civil  et  d'un  avion  mili- 
taire.  Le  graphe  equivalent  dans  lo 
formalisme  habituel  aurait  AtA  le  sui¬ 
vant  : 


Lo  traducteur  OCA/KEE  a  lui-mAmo  AtA 
Acrit  on  KEE.  KEE  (Knowledge  Engineering 
Environment)  est  un  environnement  de  dAve- 
loppement  basA  sur  CommonLisp  destinA  aux 
applications  mettant  en  oeuvre  un  systAme 
expert  raisonnant  sur  une  base  de  connais- 
sance  structurAe  grSce  4  une  reprAsonta- 
tion  objet.-  Outre  les  fonotionnalitAs  d'un 
langage  de  frames,  1' interface  trAs  convi- 
vialo  (multi-fenAtrage,  affichago  de 
graphes...)  a  facilitA  le  dAveloppem.ent  du 
traducteur. 

Grace  4  la  similitude  des  concepts  de 
I'OOA  et  de  ceux  des  LOO,  1 ' implAmentation 
des  aspects  statiques  de  la  mAthode  n'a 
pas  posA  de  problAmes  particulier  ;  par 
exemple,  la  notion  de  "facette  d'attribut" 
et  en  particulier  celle  de  "valueclass", 
qui  dAfinit  le(s)  domaine(s)  de  valeur 
d'un  attribut,,  a  permis  d' iraplAmenter  la 
notion  de  lien  d' instances. 

Pour  les  aspects  dynaraiques  de  la  mAthode,. 
deux  fonotionnalitAs  de  KEE/ComirionLisp  ont 
AtA  dvantageusement  utilisAes  ;  il  s'agit 
de  la  notion  de  “dAmon"  (ou  de  "valeur 
active")  et  de  la  notion  de  parallAlisme. 
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On  ''d6mon"  est  une  action  associ^a  A  un 
attribuc  at  qui  ast  d6clench4a  i  chaqua 
acc&s  i  ca  darniar  (an  lacture,  an  6critu- 
re  ou  las  deux).  Dana  I'anvironnement  KEE, 
un  dfemon  particulier,  as30ci6  i  chaqua 
attxibut  d'un  objet,  ^valua  laa  conditiona 
dea  tranaitiona  aorcantaa  da  I'^tat  cou- 
rant  da  1' objet  :  ai  la  nouvelle  valour 
valide  une  condition  da  tranaition, 

1' action  da  tranaition  aaaociie  eat  alora 
effectu6e.  La  dynamique  eat  ainai  entiire- 
ment  dirig^e  par  lea  changementa  da  valour 
dea  attribute. 

L'exiatence  du  "parall^liame"  eat  n6cea- 
aaire  pour  impl^menter  la  aollicitation  da 
aarvice  non  bloquante  pour  1' objet  daman- 
dour  ;  lea  fonctionnallt6a  do  "multi-taa- 
king"  offertea  par  CommonLiap  ont  permia 
do  r^aliaer  une  primitive  d' envoi  da  maa- 
saga  aaynchrona 

"3end(objat_daatinataire, aervica) ". 

S.Z.S.L'anvironnaiaant  da  oaquattaga 

Oe  la  mSme  manidre  qua  I'anvironnement 
SART/ADA,  I'anvironnement  OOA/KEE  offre  au 
apAoifiour 

-  dea  moyena  da  tragabilitA  du  code 
maquette  par  rapport  i  la  deacription 
OOA  corraapondante, 

-  diffArenta  modea  d'exAcution, 

-  un  langage  da  dAfinition  da  1' interfa¬ 
ce  da  aimulation  :  il  comporte  un  cer¬ 
tain  nombra  da  primitivea,  dont  la 
primitive  "DISPLAY"  qui  parmet  d'aaao- 
cier  i  un  attribut  une  reprAaentation 
graphique  (jauge<  thermomAtre,  comp- 
teur...)  qui  viaualiae  aa  valour.  Un 
autre  primitive  "DISPLAY_2D*  parmet  da 
viaualiaer  dana  un  plan  I'Avolution 
dea  valeura  da  deux  attribut a. 

Si,  comma  pour  I'anvironnement  SABT/ADA, 

1' inatrumentation  du  code  qAnArA  a  AtA  une 
dea  techniquea  d' implAmentation  da  I'envi- 
ronnement  da  maquottage,  la  calcul  aymbo- 
lique,  foncemant  du  langage  Liap,  a  accA- 
lArA  la  dAveloppament  at  rAduit  le  code 
gAnArA. 

Une  dea  fonctionnalitAa  particuliAre 
induite  par  la  mAthoda  eat  la  mAcaniame 
d' inatanciation.  La  mAthode  OOA  dAfinit 
dea  claasea  d' objet  et  lea  relationa  entre 
lea  futurea  inatancea  de  cea  claaaea.  Une 
aimulation  comporte  une  premiAre  phaae 
d' initialiaation  qui  oonaiate  A  crAar  lea 
inatancea  et  A  initialiaer  lea  relationa 
qu'ellea  ont  lea  unea  avec  laa  autrea. 
C'est  grAoe  aux  cardinal itAa  dea  relationa 
qua  ae  fait  la  crAation  doa  inatancea  ;  la 
puisaance  du  mAcaniame  d' inatanciation 
permet.  dAa  la  phaae  d' initialiaation,  de 
mettre  en  Avidence  lea  Aventuela  problAmea 


de  cycle  dana  lea  liana  entre  inatancea  et 
d'y  ramAdiar  par  dea  modificationa  de  la 
apAcification. 

3.2.4.Dn  anvironnamant  "dAdlA"  :  Bypaxtaxt 
at  dlalogua  B/M 

L'environnemant  de  spAcification/maquet- 
tage  OOA/KEE,  4  vocation  "fonction  nouvel¬ 
le",  a  AtA  utilisA  pour  aider  A  formaliaer 
la  fonction  ELS  (Electronic  Library 
Syatem)  :  ca  travail  a  about!  A  un  outil 
de  apAcification/maquettage  pour  laa 
applicationa  ELS. 

Une  application  ELS  conaiate  A  automatiaer 
la  conaultation  par  la  pilota  dea  docu- 
menta  A  bord  de  I'avion.  Une  telle  appli¬ 
cation  eat  deatinAe  A  Atre  apAcifiAe  en 
Aquipe  intAgrAe  avec  la  compagnie  aArienne 
at  lea  pilotea,  d'oii  la  nAceaaitA  da  dia- 
poaer  d'un  outil  oA  apAcification  et 
maquettaga  aont  indiaaociablea. 

L' outil  parmet  de  dAfinir  la  atructure 
logique  da  touta  la  baae  de  donnAea  docu- 
mentaire  embarquAe  et  la  logique  d'accAa 
par  le  pilote  A  cotte  baae  de  donnAea.  Le 
concept  clA  eat  celui  d' "hypertext"  :  lea 
documenta  aont  reliAa  lea  una  aux  autrea 
par  dea  liana  typAa.  Une  application  ELS 
conaiate  an  fait  A  naviguer  dana  la  baae 
de  donnAea  documentaire  en  auivant  lea 
chemina  d'accAa  dAfinia  par  cea  liena. 

Pour  cela,  la  pilote  diapoae  d'una  inter¬ 
face  utiliaateur  lui  permettant  grAce  A  un 
moyen  de  dAaignation  (de  type  aouria)  de 
aAlectionner  dea  portiona  de  documenta  et 
d' accAder  A  ceux  auxquela  ila  aont  reliAa. 

3. 3. Atelier  intAgrA  de  apAcification  / 
aaquettage 

L' atelier  de  apecification/roaquettage 
regroupe  diffArenta  environnementa  de  spA- 
cification/maquettage  et  met  A  la  diapoai- 
tion  dea  utiliaateura  dea  moyena  rApondant 
aux  troia  beaoina  d' intAgration  qui  aont  ; 
intAgration  de  techniquea  de  maquettaga 
entre  ellea,  intAgration  de  mAthodea  de 
apAcification  entre  ellea  afin  d' en  dAfi¬ 
nir  de  nouvellea  et  intAgration  d'une 
mAthode  avec  une  technique  de  maquettage. 

Lea  travaux  d' implAmentation  effectuAa 
juaqu'A  prAaent  dana  le  cadre  de  1' atelier 
de  "spAcification/maquottage"  et  prAaentAa 
dana  ce  paragraphe  ont  conduit  A  dea  rAa- 
liaationa  logiciellea  qui  doivent  Atre 
conaidArAea  comme  dea  maquettes  deatinAea 
A  valider  lea  beaoina.  Ellea  ont  AtA  rAa- 
liaAa  directement  aoua  UNIX  alora  que  lea 
moyena  d' intAgration  qui  aeront  effective- 
ment  retenua  par  la  auite  a'appuieront  aur 
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des  normes  et  produits  du  marchg  ;  parmi 
ceux-ci,  la  norme  PCTE  ot  los  outila  aup- 
ports  (EI'iERAUDE) ,  des  environnements  de 
type  EAST  ou  ENTREPRISE  sent  k  I'Atude. 

S.S.l.Stmctura  d'aocuail 

3.3.1.1. Coucha  da  communication 

La  croissance  des  besoms  en  conununica- 
tion  qui  s'explique  par  1' h6t6roqAn4itA 
des  concepts  liAs  aux  mAthodes  de  specifi¬ 
cation  et  aux  techniques  de  maquettage 
ainsi  que  par  la  distribution  des  outils 
correspondants  sur  un  rAseau  de  stations 
de  travail,  a  nAcessitA  la  definition  et 
la  realisation  d'une  couche  de  communica¬ 
tion  [141  . 

Crete  4  cette  couche,  lea  moyens  informa- 
tiques,  logiciels  et  materiels,  sur  les- 
quels  tournent  les  environnements  do  sp6- 
cif ication/maquettage,  deviennent  transpa¬ 
rents  et  le  nombre  et  la  localisation  des 
stations  de  travail  sur  le  reseau  sent 
masques  au  specifieur. 

Ceci  est  rendu  possible  par  la  faculte  de 
fairs  communiquer  des  langages  de  program- 
mation  entre  eux  :  ainsi  1' interface  entre 
ADA,  KEE/CommonLlsp,  FORTRAN,  C  ot  LeLlsp 
eat  realisee  par  des  primitives  du  type 
SEND(destinataire,  message)  et 
RECEIVE (emotteur,  message).  L' implementa¬ 
tion  de  ces  primitives  fait  appel  aux 
diverses  fonctionnalites  de  la  couche  de 
communication  d'UNIX,  en  particulier  RPC 
et  los  SOCKETS. 

L'  integration  des  techniques  do  maquettage 
consisto,  4  partir  de  la  couche  "communi¬ 
cation  entre  langages",  4  definir  des  pri¬ 
mitives  de  plus  haut  niveau  :  par  exemple, 
la  primitive  ADA 

"ADD_FACT (ba30_de_connai33ance,  fait) "  met 
4  jour  la  base  de  cor.naissance  d'un  syste¬ 
ms  expert  tournant  dans  1' onvironneraent 
KEE. 

3 . 3 . 1 . 2 .  Repository  comnun 

La  structure  d'accueil  dispose  d'un 
"repository"  qui  permet  d' avoir  une  base 
de  stoo)tage  des  donn6es  commune  4  tous  los 
environnements  de  sp6cif ication/maquetta- 
ge.  Dans  cette  base  de  donn6es  sont  stoc- 
)c6es  des  informations  de  tout  niveau  :  on 
y  trouve  aussi  bien  les  diffferentes  speci¬ 
fications  et  les  maquettes  associees  que 
des  elements  d'une  granularite  inferieure 
comme  ceux  figurant  sur  une  specification 
:  par  exemple,  pour  SART,  on  trouvera  les 
flux  de  donn6es,  les  fonctions,  les 
PSPEC...,  pour  I'OOA,  les  classes,  les 
relations,  les  automates. . . 


Ce  "repository"  permet  de  faciliter 
1' integration  d'une  methode  avec  une  tech¬ 
nique  de  maquettage  en  disposant  d'une 
representation  interne  independante  de  la 
notation  graphique  ou  textuelle  de  la 
methode  et  4  partir  de  laquelle  le  gen6ra- 
teur  de  code  est  defini. 

3 . 3 . 2 . Integration  das  netbodas 

L' integration  de  differentes  methodes  se 
base  sur  1' existence,  pour  chaque  n-ethode, 
d'une  description  formelle  de  sa  syntaxe 
et  de  sa  semantique. 

C'est  4  partir  de  la  description  formelle 
d'une  methode  que  sont  dAfinies  : 

-  la  representation  interne  dans  le 
repository  commun  des  specifications 
etablies  en  utilisant  la  methode  en 
question, 

-  les  verifications,  syntaxiques  et 
semantiques,  liAes  4  cette  mAthode. 

La  description  formelle  d'une  mAthode 
dAfinit  done  un  outil  support  4  cette  nou- 
velle  methode. 

L' integration  de  deux  mAthodes  consiste  4 
enrichir  les  descriptions  formelles  de 
chacune  des  deux  mAthodes  :  on  aura  ainsi 
dAfini  une  nouvelle  methode  intAgrAe  ainsi 
que  I'outil  support  associA  et,  gr4ce  4  la 
couche  de  communication,  1 ' integration  des 
techniques  de  maquettage  liAes  aux  deux 
mAthodes  initiales  sera  assurAe. 

L' outil  choisi  pour  supporter  le  travail 
de  description  formelle  des  mAthodes  est 
un  outil  du  marche,  GRAPHTALK  rAalisA  par 
XEROX.  A  partir  d'une  definition  graphique 
et  textuelle  d'une  mAthode  (graphique  pour 
la  syntaxe  et  textuelle  pour  la  sAraan- 
tique) ,  il  permet  la  mise  4  gour  du  "repo¬ 
sitory"  commun  oO  les  descriptions  for¬ 
melles  des  diffArentes  mAthodes  sont 
elles-m§mes  stocjcAes.  Les  verifications 
liAes  4  la  mAthode  resultant  de  I' integra¬ 
tion  des  mAthodes  exploitent  ces  descrip¬ 
tions  formelles  enrichies. 


SART/ADA  OOAfKEE  VISA 

ADA  FORTRAN  LISP 

SART  OOA 

couch*  do  communicoilon 

REPOSnORY 

UNIX 


-  Les  diffArentes  couches  de  1' atelier  - 
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4.  Conclusion 

Ces  travaux  de  d4finition  et  de  mise  en 
place  d'outils  de  specification  et  de 
maquettage  ont,  pour  la  plupart,  6t6 
finances  par  des  fonds  propres  SEXTANT. 

Ils  ont  largement  beneficie  du  soutien  de 
plusieurs  pro jets  operationnels,  civils  et 
militaires,  dans  le  domaine  de  la  conduite 
du  vol  :  on  pout  citer  le  SOP  (Systeme 
d' Optimisation  des  Performances)  pour 
avions  d'armes,  la  fonction  ELMS 
(Emergency  Landing  Managment  System) ,  le 
preset  PROFIL  mene  en  collaboration  avec 
1' Aerospatiale,  I'ELS  (Electronic  Library 
System)  et  plusieurs  applications  des  sys- 
temes  experts  aux  logiciels  de  gestion  du 
vol. 

Ceci  a  permis  la  definition  de  solutions 
parfaitement  adaptees  aux  besoins  et  lea 
outils  associes  sent  mis  en  place  selon  un 
calendrier  qui  autorise  leur  utilisation 
dans  le  cadre  d' importants  presets  actuals 
tel  que  le  CET  (Calculatour  '"Elaboration 
de  Trajectoirea)  du  RAFALE. 

Oe  facon  similaire  A  la  phase  de  ap6cifi- 
cation/maquettago,  une  etude  eat  menee 
ccncernant  la  phase  de  prototypage.  Cette 
phase  vise  A  valider  une  fonction  dans  son 
dialogue  avec  lea  systAmes  exjstants  A 
bord  de  1' avion  :  le  principal  problAme 
pose  par  ce  type  de  validation  est  de 
faire  dialogue!  une  maquette  fonctionnelle 
(dont  le  developpement  a  fait  abstraction 
des  prob.'Ames  de  performance  lies  au  mate¬ 
riel)  avec  des  equipements,  reels  ou  simu- 
les,  necessitant  des  temps  de  rAponae 
proches  de  ceux  attendus  en  vox. 

Les  deux  principaux  axes  de  cette  Atude 
des  moyens  de  prototypage  sont  le  passage 
dutomatique  d'une  specification  fonction¬ 
nelle  ou  de  la  maquette  asaociAe  A  un  code 
executable  en  tempa-rAel  et  1' evolution 
des  moyens  materials  et  logiciels  pour 
recevoir  le  code  et  fournir  I'environne- 
ment  nAcessaire  A  son  execution. 

La  competence  en  spAcif ication/maquettage, 
acquise  lors  des  Atudes  et  travaux  liAs  A 
la  rnise  en  place  de  ces  environnements,  et 
la  veille  technologique  assurAe  en  perma¬ 
nence  sur  les  techniques  logicielles  avan- 
cAes  permettent  A  la  Division  Conduite  du 
Vol  d'etre  prAte  A  mettre  sur  pied  trAs 
rapidement,  1' environnement  dAdiA  A  la 
specification  et  A  la  validation  par 
iiaquettage  et/ou  prototypage  de  toute  nou- 
velle  fonction  que  la  division  pout  otre 
amenAe  A  dAvelopper. 
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contwxlon  tc  djt«  ftCor* 


with  p^mod«l«_SArt;ut« 
q«n«r:c 

1  isce^f IuH_sort4nt  :  1 1 lux, 

P4CX49C  p_^conn«xLon  is 

t4sk  t4ch«^coni>«Mion  is 

•nCry  ricsvoir^flux  (  un^flux  :  x**  flux); 
end  tsehs^coPMXLon; 

•nd  p_conn«Kion; 


pspec 


with  p^«od«l«_S4rt;us«  p^Mxlsls^ssrt; 

9«n«rie 

with  proc«4ur«  trsitsasnt^pspsc; 
liSts^fluR^sorCsnt  :  listS_d«_fluM; 

pACk49«  p.pspsc  is 

cssk  9sr«r  sntrMs  is 

entry  r««*voir^fluM(un_f Lux  :  flux); 

•nd  9«r«r,«ncr««s;'' 

tssk  tr4it«a»nt; 

tsik  coAtrol«ur  iocsl  is 
•Qtry  eoACroI«r^E  0; 

•ntry  contr«l«r‘'TlIXOQBX; 

•ncry  mi 
•ntry  flni 

•nd  e«ntr«l«ur^locsli 
CAsk  yinic^denn—s  i« 

•ntry  rio*v«ir^doAnMs(  un  (lux  :  fluKjd*jdonAM«)i 
•ntry  vsl«ux^«M.*Ant^  (  v«T  :  out 
•ntry  v«l«ttr2t<Ml\o  (  vaI  i  out  ( 1  ux^^^dSnnoos ) i 
•nd  9of  f^doiwoi; 

CAsk  9«r«r  ••rtloo  is 

•ntry  produir«(uo  (lux  :  in  fluxli 

•ncry  MHiv«l^«tAtT«tAt  :  In  «CAt^(onctionl; 

•nd  9«r«r_««rti««i 

•nd  p^pspoci 


cspoc 


•ith  p^aoiolG^sortiuso  pjao4sl«.sArt; 

9<nsric 

l^AUtOAStO  :  AUtOSMCOI 
pAck«^  p_c«poc  !• 

CASk  CAChO^CApOC  is 

•ntry  rtoiwol efflux  I  un_contrelx  :  in  (luxi; 
•nd  tACh«_csp*G/ 

•nd  p^cspoci 


(•Action 


•itii  p_Mdol«.«4rt;u«o  p_«o4sl«_s4rt; 

«MMClC 

flux  Mrtxnt  (oACtiMi  :  list*  dv^flux; 
nuK'«iitrsiii*'fil«  I  li«t«j««_Tlux; 
•IwoM^fcuckroo  I  pQsitlv*; 

pirk if  p^fonctlon  is 

tssk  tsdMi  fonctioA  is 

••try  roc«o«ir_flus  i  l«_flux  :  in  (lux); 

•nd  tscto^fsMctisd; 

•nd  p_(«iictiMii 


ANNEXE  1 
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AGLAE  -  Atelier  de  Genie  Logiciel  de  I'aerospotiale  Engins 


par 

Jocelyne  HAMON 

aerospatlale 

2,  rue  Beranger  92320  CHATILLON  (FRANCE) 


R6sum6 ;  La  conception  des  syst&mcs  tcmps-rdel  csi  un  probldme  fonement  combinatoire  mais  uts  contraint.  Lcs  experts 
proeddeni  par  des  transformations  de  la  spdcification  technique  de  besoin  en  des  systdmes  dquivaicnts,  satisfaisant  Ics  con- 
traintes  du  tcmps-rdel  (frdqucncc,  retard,  prioritd,  communicauons).  AGLAE  est  un  atelier  logiciel  comprenant  unc  base 
de  donndes  orientde  objets  des  composants  et  algoriihmes  utilisds  ;  une  base  de  connaissanccs  reproduisant  Ic  raisonne- 
ment  de  nos  meilleurs  experts ;  un  systdme  de  simulation  permettant  la  validation  des  architectures  matdriclles  ct  logicicl- 
les  proposdes.  AGLAE  est  un  programme  de  satisfaction  de  contrainies  guidd  par  des  heuristiques  (relations  de  prdfdrencc 
des  experts).  La  spdcification  forme  la  racinc  d'un  arbre  ET/OU  ou  chaque  nccud  (fonciionnellcment  dquivalent)  corres¬ 
pond  h  I’application  d'une  transformation  (ensemble  de  rdgics).  Lcs  fcuillcs  de  I  'arbre  final  sont  soumiscs  h  unc  simulation 
tcmps-rdel.  La  recherche  est  dirigdc  par  Ics  ddpcndanccs  qui  sont  gdndrdcs  comme  dans  un  ATMS  :  Ics  causes  d’dchcc 
sont  analysdes  ct  Ics  conditions  minimalcs  sont  rctcnucs  pour  dvitcr  la  rdpdtition  de  ccs  causes  lors  des  rctours. 


I.  INTRODUCTION : 

Les  systdmes  de  conception  el  de  validation  conticn- 
nent  gdndralcmcnt  des  outils  (qui  nc  sont  pas  ndcessairc- 
ment  sdpards)  de  synihdsc,  d’analyse  ct  de  lest 
(simulation). 

Un  oulil  do  synthdse  (de  sysidinc  lemps-rdel)  aide  Ic 
concepteur  dans  la  production  d'une  architecture  maid- 
rielle,  ct  d'un  ensemble  de  programmes  ii  pattir  d'une 
description  de  la  fonction  que  doit  remplir  ce  sysidmc  et 
des  contraintes  lidcs  aux  donndcs  en  enude  ct  cn  sortie. 

Un  outil  d'analysc  permei  au  concepteur  de  vdrifier 
qu'un  systdme  remplit  la  fonction  avec  les  performances 
ddsirdes  (il  contient  un  vdrificaieur  de  rdgles  de  consuuc- 
tion  cl  de  satisfaction  de  contraintes). 

Un  outil  de  simulation  c.st  indispensable  pour  s'assu- 
rer  du  respect  des  contraintes  temps-rdcl,  car  I'arrivde 
des  donndes  peut  avoir  un  caracldre  atdaioire  (distribu¬ 
tion  dans  le  temps)  que  I 'analyse  ne  peut  pas  toujours 
prendre  en  compte ;  il  sc  peut  que  la  simulation  fasse  ap- 
paraltre  des  situations  dans  lesquelles  une  ou  plusieurs 
des  contraintes  temps-rdel  sont  violdes.  La  specification 
technique  de  besoin  prdcise  si  ccs  violations  sont  accep- 
tablcs  de  manidre  transiloirc  ou  totalcment  prohibdes. 
Dans  ce  cas,  un  autre  systdme  doit  etre  con^u,  puis  simu- 
Id  et  ainsi  de  suite ... 

L’atelier  AGLAE  ’“’(Atelier  de  Gdnie  Logiciel  de 


1.  AGLAE  eiit  une  marque  ddposdc  par  la  socidlC 
aeiospatialo. 


aerospatlale  Engins)  ddcni  dans  cct  article,  est  un 
systdme  expert  qui  reproduit  le  raisonnement  d'un  grou- 
pc  de  conceptcurs  de  systdmes  tcmps-rdel.  II  a  pour  but 
cssciitiel  d’dlrc  un  systdme  de  conception  ct  de  valida¬ 
tion  pour  calculalcurs  embarquds  ou  lout  autre  sysidmc 
tcmps-rdel. 


II.  LES  ATELIERS  DE  GENIE  LOGICIEL  : 


Lcs  progrds  enregistrds  res  quinze  demidres  anndcs 
sur  la  production  de  composants  matdriels  onl  considdra- 
blcmcnt  modifid  le  pare  des  systdmes  informatiques.  Pa- 
ralldlemcnt,  si  Ton  examine  I'dvolulion  du 
ddvcloppemeni  du  logiciel^,  on  constate  que  I'effort 
s'esi  d'abord  porid  sur  I'aciiviid  de  codage,  grace  aux 
langages  de  haul  niveau  et  aux  techniq  es  de  program- 
mation  suucturdc.  Par  conire,  la  qualitd  des  documents 
de  spdcification  ct  de  conception  reildtc  le  plus  souvent 
la  valeur  de  I'analyste  plutdt  que  la  rigueur  d'une  mdtho- 
dologie  adaptde,  ce  qui  conduit  les  chercheurs  d  aborder 
le  ddveloppcmcnt  du  logiciel  sous  un  nouvel  angle.  C'est 
ainsi  qu’ont  dtd  identifides  puis  mesurdes  les  diffdrentes 
activitds  de  production  du  logiciel.  L'existence  mdme 
d'un  cycle  de  vie  standard  a  did  reconnue  et  nomialisde. 


2.  Lc  logiciel  esl  I'ensemble  des  programmes, 
procddCs  ct  rCgles,  cl  £vcniucllemenl  de  la  documen¬ 
tation,  relalifs  au  fonclionnement  d'un  ensemble  de 
uaitcmcnl  de  I’lnfomiation  (arrcie  du  22.12.1981). 
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La  figure  1  planche  1  montre  le  cycle  de  vie  du  logi- 
ciel  propv)s6  par  1’ Association  Fran? aise  pour  le  Controle 
Industriel  de  Quality  (AFCIQ). 

Cette  aporoche  Gdnie  Loeiciel  de  la  fin  dcs  anndes  70 
s’est  traduite  par  des  lentatives  d’intdgration  (au  niveau 
de  Torganisaiion  du  projct  comme  au  niveau  fonction- 
nel)  de  procddures,  mdthodes,  langages  et  outils  qui  fa- 
vorisent  la  production  ct  la  maintenance  de  composants 
logiciels  de  qualitd. 

Si  Ton  sc  r6fSre  rarteuS  ministdricl  du  30.12.1983, 
on  appclle  Gdnie  Logiciel :  "I’cnsemble  dcs  activiiiSs  de 
conception  et  de  misc  cn  oeuvre  des  produits  et  des  pro¬ 
cedures  tendant  &  rationaliser  la  production  du  logiciel  ct 
son  suivi." 

Arrcte  tr6s  important  puisqu’il  s’agissait  alors  de  rccon- 
naitre  I’existcnce  du  G6nic  Logiciel',  connu  sculcmcnt 
de  quelques  initids.  Vingt  ans  apris,  le  Gdnic  Logiciel 
fait  I’objet  de  nombreux  programmes  nationaux  ct  inter- 
nationaux. 

Scion  P.  JAULENT^  Ic  Gdnie  Logiciel  cst  un  ensem¬ 
ble  de  “procedures,  methodcs,  langages,  ateliers,  impo¬ 
ses  ou  precomses  par  les  norincs  adaptdes 
I’environnement  d’utilisation,  afin  de  favoriscr  la  pro¬ 
duction  ct  la  maintenance  de  compo.sants  logiciels  de 
qualite." 

En  cc  qui  conceme  les  procedures,  la  mise  en  place 
d’une  organisation  de  production  dc  systSmes,  qui  per- 
met  au  scin  d'un  cadre  industriel,  dc  maitriscr  la  qualite 
dcs  produits,  les  couLs  ct  les  ddlais  de  realisation  repose 
sur  le  principc  dc  ddeoupage  du  processus  de  ddvcloppc- 
ment  dc  systdmes  cn  plusieurs  phases,  Cc  ddeoupage 
normalise  (DoD  2167,  GAM  TI7, ...),  appcld  cycle  de 
VIC  d’un  svstdme.  cst  constitud  de  six  phases. 

Phase  1 ;  Orientation  -  Faisabilitd  des  bcsoias 
Cette  dtape  ddcrit  les  besoins  formulds  par  le  futur  client, 
et  non  comment  les  obtenir  cn  tenant  compte  par  cxcin- 
plc,  des  contraintes  dc  cout,  dc  ddlai,  de  temps  d’cxdcu- 
tion,  de  precision  dcs  calculs. 

Le  document  erdd  lors  de  cette  phase  est  appcld  Cahier 
des  Charges  Fonctionncl  (CdCF- 1  nornie  AFNOR 
NFx50-151). 

Phase  2 :  Conception  du  systdme  et  validation  des  be¬ 
soins 

La  conception  d’un  systeme  suppose : 

-  une  analyse  statiaue.  faite  ^  partu  du  Cahier  des  Char¬ 
ges  Fonctionncl,  formalisde  par  une  Specification 

Technique  de  Besoms  (STB), 

■  une  analyse  dvnamiaue.  faite  h  partir  de  la  Spdcifica- 


1  1968  :  Conference  OTAN  sur  le  Genie  Logiciel , 
c’esl  I’annec  du  conslal  de  la  crisc  du  logiciel  el  I’u- 
iilisaiion  pour  la  premiere  fois  de  I’expression  "Sofi- 
warc  Engineeruig”. 

2.  Pairick  JAULENT,  Genie  Logiciel  les  methodes. 
Editions  COLIN,  1990 


tion  Technique  de  Besoins,  formalisde  par  un  prototy- 
page. 

L’analyse  statique  est  composde  dc  deux  dtapes  ;  la  con¬ 
ception  prdliminaire  et  la  conception  ddtaillde  d’un  sys- 
tdme. 

La  conception  prdliminaire  permet ; 

-  d’dnumdrer  et  de  ddcrire  les  travaux  a  effectucr, 

-  d’analyser  les  exigences  de  qualitd, 

-  de  ddfinir  la  politique  de  maintenance, 

-  d’identificr  les  techniques  de  toldrance  aux  fautes  h 
mettre  cn  oiuvrc  ct  dtudier  leurs  consdquences, 

-  d’dtudicr  les  conditions  dc  rccctte  du  systdme, 

-  dc  proedder  h  I'analyse  fonciionnclle  des  besoins  h  par¬ 
tir  du  Cahier  des  Charges  Fonctionncl,  ceci  afin  dc : 

■*  prdciser  les  fonctions  techniques  et  d’identifier  les 
points  critiques  dc  chaque  solution  envisagde, 

*  d’dtablir  Tarchitccture  du  systdme  (ct  des  sous-systd- 
mcs). 

D’un  point  dc  vuc  organisationncl,  cette  dtape  permet  de 
ddfinir  la  stratdgie  industriclle  qu’il  faudra  appliquer  sur 
le  programme. 

Les  taches  cnirepriscs  au  cours  de  I’diapc  de  conception 
ddtaillde  d’un  systdnie  compidtent,  affluent  ct  vahdent 
les  aspects  entrevus  h  I’dtapc  prdeddente  Cellcs<i  dd- 
bouchent  sur  une  nouvclle  ddition  dcs  Spdcifieations 
Techniques  dc  Besoms 

L’analysc  dynamique  des  besoms  maintenant  cxprimds, 
sc  traduit  par  la  rdalisation  d’un  prototype.  Celui-ci  doit 
nous  offrir  la  possibilild  d'cxpdrimcntcr,  rapidement  ct  h 
moindres  frais,  le  bicn-fondd  dc  ccrtaincs  iddes,  qu’il 
s’agissc  d’iddes  “fonctionnclles”,  d ’iddes  archiicctura- 
les,  ou  simplcmcnt  d’iddes  conccmani  I’litilisation  du 
systdme  que  Ton  doit  ddvcioppcr. 

II  faut  savoir  qu’il  existe  deux  types  dc  prototypages :  le 
prototypage  rapide  et  Ic  prototypage  dvolutif. 

Le  proiotvnaite  rapide  eonsiste  5  rdaliscr  tout  ou  partie 
du  futur  systdme  avee  dcs  mdthodcs  ct  dcs  outils  disixr- 
nibles,  ct  a  pour  but  de  vdrificr  la  cohdrenee  des  diverses 
contraintes  et  dc  les  prdciser,  Malheurcusemcni,  Ic  cout 
ct  le  temps  de  ddveloppcment  d’un  tel  prototype  appro- 
chent  souvent  ceux  d’une  impidmentation  rdelle. 

Le  prototypage  dvolutif  est  une  partie  intdgrante  du  dd¬ 
veloppcment  du  systdme,  quoique  n’dtant  pas  intdgrd  au 
moddle  classique  de  ddveloppcment  du  logiciel,  il  se 
substitue  aux  dtapes  de  conception  et  permet  de  vdrifier 
les  cohdrenccs  ct  les  choix  h  ces  niveaux. 

Dans  les  deux  cas,  I’utilisateur  du  systdme  peut  dvaluer 
Ic  comportemeni  du  prototype,  et  le  comparer  d  celui 
qu’il  attcndait.  Si  le  prototype  ne  ddmontre  pas  les  carac- 
idristiques  aitendues,  il  peut  dventuellement,  aprds  avoir 
identifid  le  probldme,  modifier  sa  spdcification.  Tout  ccci 
lui  permet  dgalement  de  ne  pas  prendre  le  risque  d’atten- 
dre  la  fm  de  la  rdalisation  du  systdme  pour  s’apercevoir. 
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^  ce  moment  I^,  que  les  id£es  en  question  sont  peut-etre 
sujettes  &  caution  ou  tout  simplement  inaddquates. 

Phase  3 ;  Ddveloppement  logiciel  du  systfeme 
Cette  phase  est  critique,  puisqu’il  s’agit  de  consiruire  (ce 
qui  n’est  pas  realisable),  suivant  un  cycle  de  vie  normali¬ 
se,  k  partir  des  documents  redigds  pr&edemment,  I’en- 
semblc  des  composanis  materiels  et  logiciels  qui 
constitueront  le  systbrne. 

Sept  sous-phases  la  composent : 

-  la  specification  fonclionnelle  du  logiciel.  donnant  lieu  i 
I’analyse  des  besoins  exprirnds  par  Ic  client  afin  de  defi- 
nir  le  futur  logiciel. 

-  la  conceniion  nreiiminaire  du  logiciel  dont  I’objectif  est 
d’apportcr  une  solution  aux  besoins  exprimds  cn  identi- 
fiant  I'architccture  du  logiciel. 

-  la  concemion  detailiec  du  logiciel  oil  cheque  compo- 
sant  identine  h  I'etapc  de  conception  preiiminairc  fait 
I'objet  d’une  conception  detailldc  qui  dderit  les  donndcs 
maniptildcs  par  les  composanis  et  les  algonthmcs  agis- 
sani  sui  res  donndcs.  Pour  cheque  composant,  les  tests 
unitaircs  lui  afferent  sont  ddfinis,  afin  de  s'assurer  que  Ic 
comiwsant  rdalisd  rdpond  h  la  description  qui  cn  a  did 
faite. 

Pour  chaque  composant,  un  document  de  conception  dd- 
tailldc  et  un  document  de  tests  unitaircs  sont  diabords. 

■  le  codage  du  logiciel.  o£i  chaque  composant  logiciel, 
donndcs  ou  algorithmcs,  est  codd  dans  le  langage  de  pro- 
grammation  choisi.  Le  code  doit  dtre  compile  ou  assem¬ 
ble,  puis  "ddvermind"  soil  par  relccturcs,  lectures 
croisdes  ou  tout  auve  moycn  de  vdrincalion. 

-  les  tests  unitaircs  de  logiciel.  lei,  pour  chaque  compo¬ 
sant  logiciel,  les  jeux  d’essais  ddrtnis  dans  la  phase  de 
conception  ddtailldc  sont  cxdcutds.  Les  rdsultats  sont  cn- 
rcgisirds  de  mfime  que  totit  dcari  par  rapport  aux  rdsultats 
attendus. 

•  rintdgration  et  tests  d'intdgration  du  logiciel  dont  I’ob- 
jeetif  est  d’obtcnir  un  ensemble  intdgrd  de  composanis 
logiciels  de  fa;on  it  constitucr  un  produit  final. 

-  la  validation  du  logiciel.  ou  certification,  dont  le  but  est 
de  ddmonmer  que  le  logiciel  ddveloppd  rdpond  cxacie- 
ment  aux  besoins  exprimds  dans  la  spdcification. 

Phase  4 :  Intdgration  matdricl-logicicl 
Chaque  eniitd  ayant  dtd  consuuitc  et  testde  sdpardment, 
il  est  ddsormais  possible  de  produire  un  systdme,  cn  intd- 
grant  matdrici  et  logiciel,  de  Ic  tester  et  de  le  certifier 
conforme  par  rapport  aux  documents  dtablis  lors  de  la 
conception  ddtaillde,  puis  de  Ic  fabriquer  en  vue  d'nnc 
utilisation  soutenue. 

Phase  5 :  Rccette  systdme  -  Validauon 

L’objcctif  de  cette  phase  est  de  ddmontrer  au  client  que 

le  systdme  ddveloppd  rdpond  effectivement  aux  besoins 


exprimds  par  le  Cahier  des  Charges  Fonctionnel  et  par 
les  Spdcifications  Techniques  de  Besoins.  Les  tests  de 
recette  s’attachent  h  contrdler  les  caraetdristiques  telles 
que ; 

-  les  fonctionnalitds  du  systdme, 

-  I’interface  homme-machine  (prdsentation  des  dcrans, 
dialogues,  rdsistance  aux  erreurs  utilisateurs, ...), 

-  Tintdgritd  '"is  donndes  (protection), 

-  les  temps  Je  rdponsc, 

-les  reprises, 

-  les  modes  ddgradds, ... 

Phased ;  Maintenance  du  systdme 
II  s’agit  de  ddlinir  une  politique  de  maintenance  liable 
pour  le  systdme  sous  la  forme  d’un  contrat,  en  tenant 
compte  des  diffdrentes  catdgories  de  maintenance  (cor¬ 
rective,  dvolutivc,  adaptative, ...). 

En  ce  qui  conceme  les  mdthodes.  produire  et  mainte- 
nir  un  logiciel  de  qualitd,  en  maitrisant  les  coQts  et  les 
ddlais  de  ddveloppement,  suppose  I’utilisation  d’une  ou 
plusicurs  mdthodes  pour  les  diffdrentes  phases  du  cycle 
de  vie  d’un  systdme.  Cependant,  I'utilisation  d’unc  md- 
thode  ndccssitc  de  bien  maltriser  scs  domaines  d’appli- 
cation,  scs  possibilitds,  mais  dgalemcnt  scs  limites,  scs 
diflicultds  de  mise  en  oeuvre, ... 

II  est  absolumcnt  ndeessaire,  si  Ton  veut  qu'une  mdtho- 
dc  apportc  les  gams  de  productivitd  cscomptds,  de  la 
choisir  en  function  de  critdres  tels  que : 

-  les  finalitds  et  slratdgics  de  rcnueprisc, 

-  les  acteurs  concemds, 

-  Ic  domainc  d’application  (gcstion,  scientiftque,  contro- 
le  de  processus, ...), 

-  les  dtapes  du  cycle  de  vie  du  systdme  couvertes  par  la 
mdthodc, 

-  le  niveau  d’outillagc  de  la  mdthodc  (papier,  intdgrd,  in- 
dusmialisd, ...). 

Les  principales  mdthodes  aujourd’hui  sont : 

-  SADT :  Structured  Analysis  Design  Technique 

(D.T.  ROSS) 

-  SD  ;  Smuctured  Design  (Rapport  IBM  :  STEVENS, 

MYERS,  CONSTANTINE) 

-  E-R  ;  Entity-Relationship  model  (P.  CHEN) 

-  SA  :  Structured  .Analysis 

(E.YOURDON,  T.  DEMARCO) 

-  JSD  :  Jackson  System  Development  (M.  JACKSON) 

-  SA-RT2 :  Structured  Analysis  Real  Time 

(I.  PlRBHAl,  D.  HATLEY) 

-  HOOD  :  Hierarchical  Object  Oriented  Design 

(BOOCH,  MATRA,  CRI,  ClSl) 


Pour  les  langages.  plusieurs  tendances  se  ddgagent 
actucllcment  dans  le  monde  informauque ; 

•  la  programmation  algorithmique  construiie  dans  le  do- 
maine  du  procddural  (FORTRAN,  PASCAL,  C)  ou  du 
modulairc  (ADA), 

-  la  programmation  purement  fonctionnelle  et  ddclarati- 
ve(L!SP), 

-  la  programmation  par  objets  (C-r-r,  SMALTALK), 
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-  ia  programmation  logique  (PROLOG). 

Chaque  entreprise,  en  fonction  de  son  experience  ou  de 
ses  objectifs  choisit  I’un  ou  I’autre  langage.  Mais  il  faui 
noter,  ^  I'heure  actuelle,  I'apparition  d’ouuls  lels  que  des 
gendrateurs  de  code  pennettant  d'automatiser  au  maxi¬ 
mum  cede  etape  de  programmation. 

Les  ateliers  de  Gdnie  Loeiciel.  quant  S  eux,  suppor- 
tent  la  mise  en  place  d’une  organisation  industnelle  de 
production  et  de  maintenance  de  logiciels  en  regroupant 
harmonieusement : 

-  les  rndthodes  reconnues  telles  que  SADT,  SA-RT,  JSD 

-  les  procedures  de  developpement  normalisees  comme 
DoD  2167,  GAM  T17 

-  les  gendrateurs  de  code  PASCAL,  C,  ADA 

-  les  outils  tels  que ; 

*  des  gestionnaires  de  projets, 

*  des  interfaces  avec  un  gestionnaire  de  configurations, 

*  des  modeics  d’estimation  des  couts, 

*  des  outils  de  qualimetrie  ct  de  maintenance  du  logi- 
ciel, 

*  des  interfaces  PAO. 

Ils  poursuivent  de  nombreux  objectifs  dont  les  pnnci- 
paux  sont ; 

-  d’augmenter  la  productivite  d’une  dquipe  de  develop- 
pement, 

-  d’ameiiorer  la  qualite  des  produits  logiciels,  c’cst-ii- 
dire  Icur  fiabilite,  Icur  evolutivite,  leur  maintcnabilite, 

•  d’aider  I’equipe  S  appliquer  les  differentes  normes  ct 
procedures,  incontoumablcs  etapes  dans  le  processus 
de  developpement, 

•  de  soulager  I’dquipe  de  inches  fasudieuses  ct  repeiiti- 
ves  telles  que  les  verifications  de  coherence  lors  des 
phases  de  specification  ct  de  conception  du  logicici, ... 


Hi.  LA  CONCEPTION  DES  SYSTEMES  TEMPS- 
REEL: 

La  conception  d'un  systbme  (conceptions  preiiminai- 
re  et  detailiee)  est  I'etape  la  plus  delicate  du  cycle  de  vie 
d'un  systime,  puisqu'elle  suppose  de  la  part  de  I’archi- 
tccte,  des  competences  sur  les  deux  principales  compo- 
sanies  en  interaction :  le  materiel  et  le  loeiciel.  En  effet, 
e’est  effcctivement  lors  de  cette  etape  que  s’cffcctuent 
les  choix  de  ce  qui  sera  fait  en  materiel  ct  en  logiciel, 
mais  egalement,  avec  quel  type  de  maiiriel  et  de  logiciel 
sera  construit  le  futur  systfeme. 

Malgre  les  nombreux  moyens  qui  permettem 
aujourd’hui  de  concevou  rarchitecture  d’un  systime, 
nous  avons  deiiberement  choisi  de  developper  noue  pr(> 
pre  methode,  et  ceci  pour  les  raisons  suivantes  : 

-  les  methodes  proposees  sur  le  marche  ne  couvrent  pas 
suffisamment  toutes  les  conuaintes  exprimees  dans  le 
domaine  du  lemps-reel, 

-  il  nous  faut  un  produit  approchant  au  maximum  le  rai- 
sonnement  de  nos  experts  dans  ce  domaine  ct  tenant 
compte  de  leurs  experiences  ct  de  leur  savoir-faire. 


La  Duection  des  Etudes,  au  sein  de  la  Division  En- 
gins  Tactiques  de  aerospotiale,  dans  son  Etablisse- 
ment  de  Chatillon,  a  realise  un  prototype  d’atelier  de 
Genie  Logiciel  lepondant  h  ses  besoins.  Cet  atelier,  nom- 
me  AGLAE  (Atelier  de  Genie  Logiciel  de  aerospotia- 
le  Engins)  a  pour  objectif  d’automatiser  les  etapes  de 
conceptions  preiiminaue  et  detailiee,  en  proposant  au 
concepteur  un  ensemble  de  soluuons,  architectures  ma- 
terielles  ct  architectures  logicielles,  adaptees  h  son  pro- 
blbme ;  elaboration  d’un  calculateur  embarque  ou  de  tout 
autre  systbme  soumis  h  des  contraintes  temps-reel. 

Si  nous  comparons  noue  demarche  avec  celle  definic 
dans  le  chapitre  precedent,  nous  pouvons  indiquer  que 
chacune  des  solutions  proposees  par  I’atelier  est  en  fait 
un  prototype  evolutif  de  la  partie  fonctionnelle  du  systb- 
me  (sans  les  interfaces  et  I’environnement).  L’utilisatcur 
peut  done  ainsi  valider  sa  specification,  h  partir  du  com- 
portement  du  systfeme  simuie  par  AGLAE.  Si  aucune  so¬ 
lution  n’a  pu  btre  produite,  alors,  I’utilisateur  peut 
modifier  sa  specification  ct  continuer  sa  recherche. 

A  partir  de  ces  remarques,  une  vue  plus  detailiee  du  cy¬ 
cle  de  vie  s’impose  (§  figure  2  planche  1). 

A  I’origine  de  cette  phase  de  conception,  ie  document 
relaut  h  la  Specification  Fonctionnelle  Technique  doit 
due  redige.  Celui-ci  detient  de  nombreuscs  informations 
qu’il  nous  importc  de  connaiuc  avant  I’uulisation  de  I’a- 

telier  AGLAE. 

I.  Specification  Fonctionnelle  Technioue : 

Tout  systbme  informatique  comprcnd  une  architectu¬ 
re  matericlle  (processcurs,  bus,  memoires,  coupleurs, .,.) 
ct  un  ensemble  de  logiciels  qui,  executes  sur  cette  archi¬ 
tecture,  realisent  une  fonction  (au  sens  mathematique  du 
terme).  Cette  fonction  est  generalcment  dbente,  dans  la 
Specification  Technique  de  Besoins  du  systbme,  comme 
une  composition  d’autres  fonctions  (qui  sont  elles-me- 
mes  des  compositions  de  fonctions  et  ainsi  de  suite).  Elle 
cst  encore  apjiciee  Specification  Foncuonnelle  Techni¬ 
que  dn  systfcme 

Dans  un  systbme  temps-reel,  la  fonction  attendue  est  gb- 
neralcment  de  conuoler  et  de  commander  un  processus. 
Pour  cela,  I’exbcution  des  programmes  est  toujours  com- 
inandbe  pai-  les  donnbes ;  certaines  donnbes  en  entrbe 
doivent  etre  prises  en  compte  dans  un  dblai  trbs  court  (fe- 
iieues  d’entrec) ;  certaines  donnbes  en  sortie  doivent  eue 
produites  h  un  instant  donnb  (feneues  de  sortie).  Les 
contraintes,  libcs  h  la  nature  des  donnbes  en  entrbe  et  en 
sortie,  peuvent  ainsi  s’exprimer  en  termes  de  frequence, 
de  retard  maximum  h  la  prise  en  compte,d’interruptions, 
de  date  de  production,  de  dates  de  consommation  mini- 
males  et  maximales, ...  Par  aillcurs,  d’autres  contraintes 
lieuvent  etre  imposbes,  comme  la  qualitb  requise  pour  le 
systbme  (choix  de  composanis,  d’architectures, ...)  et  la 
precision  des  calculs. 
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La  conception  de  rarchitecture  mat6rielle  est  sunitaire  ^ 
la  construction  d’un  circuit  ^lectiique  ou  £lectronique 
simple,  et  est  totalement  pris  en  charge  par  AGLAI  Au 
contiaire,  les  logiciels,  eux,  ne  sont  pas  census  par 
AGLAE,  le  code  des  algorithmes  de  base  (fonctions  616- 
mentaires)  figure  dans  la  Sp6cification  Fonctionnelle 
Technique. 

L’ organisation  du  logiciel  sur  le  mat6riel  peut  ainsi  6tre 
vu  comme  un  ordonnancement,  mais  h  la  diff6rence  de 
celui  d’un  atelier,  les  thches  sont  interruptibles  et  du  fait 
des  asservissements  (boucles  ou,  pour  deux  program¬ 
mes,  les  donn6es  produites  par  I'un  h  un  instant  t  sont 
consomm6es  par  I’autre  h  un  instant  t’,  avec  t  sup6rieur  h 
t’),  il  s’av6re  n6cessaire  de  g6rer  des  communications  et 
des  rendez-vous  h  dates  fixes.  E)e  plus,  cette  organisation 
est  telle  qu’elle  doit  v6rifier,  h  la  fois  la  fonction  deman- 
d6e,  mais  6galement  les  contraintes  expnm6es  (le  plus 
souvent  non  relaxables). 

Le  prab!6me  a  6t6  6tudi6  sous  tous  ses  aspects  (objets. 
moniteurs,  parall6lisme, ...).  Les  r6sultats  sont  utilis6s 
dans  les  connaissances  d’AGLAE,  soit  pour  d6crire  Ic 
syst6me,  soit  sous  la  forme  de  contraintes  h  respecter, 
soit  sous  la  forme  de  rhgles  de  transformation  de  syst6- 
mes. 

2.  Exemple : 

Soit  la  Sp6cification  Foncuonnelle  Technique,  figure 
3  planche  2. 

La  fonction  PHASE-VOL  est  d6finie  comme  une  com¬ 
position  des  fonctions  PILOTAGE  et  RECALAGE. 

La  foncuon  PILOTAGE  est  elle-mSme  d6compos6e  en 
deu.  sous-fonctions : 

-  PILOTAGE-LENT, 

-  PILOTAGE-RAPIDE. 

Ces  deux  fonctions  se  distinguent  par  lour  fr6quence 
dont  Tune  est  plus  rapide  que  I’autre. 

Les  fonctions  produisent  et  consomment  diff6tenies  don- 
n6es 

■  PILOTAGE-LENT  consomme  la  donn6e  POS-MACH 
et  produit  la  donn6e  GAIN, 

-  PILOTAGE-RAPIDE  consomme  les  donn6es : 

•  GAIN  produite  par  PILOTAGE-LENT, 

•  ACC-COMM  produite  par  la  fonction  RECALAGE, 

•  SOUS-CYCLE-0  et  SOUS-CYCLE-l  produites  par 
les  ressources  extemes  (bus  d’entr6e-sorUe). 

Cette  fonction  produit  la  donn6e  nomm6e  INCIDENCE. 

La  fonction  de  RECALAGE  consomme  les  donn6es : 

•  SOUS-CYCLE-l  issue  comme  pr6c6demment  d’une 
ressource  exteme, 

•  INCIDENCE  produite  par  PILOTAGE-RAPIDE. 

II  faut  noier  qu’INCIDENCE  est  une  donn6e  asser- 
vie,  e’est-h-dire  que  la  donn6e  utilis6e  par  RECALA¬ 
GE  provient  de  la  p6riode  pr6c6denle.  Ceci  se  fait 
g6n6ralement  quand  la  mise  h  jour  des  donn6es  n’est 
pas  primordiale  pour  les  nouveaux  calculs,  ou  quand 
cette  donn6e  n’a  pas  le  temps  d’Sbe  pnse  en  compie 
dans  la  p6riode  m6me  ou  elle  est  produite. 


Trois  donn6es  sont  produites  par  RECALAGE : 

*  SORTIE- 1-(X)MM  envoy6e  sur  une  ressource  exter- 

ne, 

*  ACC-COMM  et  POS-MACH  absorb6es  par  PILO¬ 
TAGE. 

Toutes  ces  donn6es  ne  sont  produites  ou  consomm6es 
qu’h  certains  moments  du  cycle  (p6node).  Ces  instants 
sont  appel6s  “fenSires”  et  sont  mat6rialis6s  par  les  res¬ 
sources  extemes  ENTREE-0,  ENTREE-1  et  SORTIE-0. 

Le  probI6me,  pour  une  telle  sp6cification,  est  de  faire 
ex6cuter  I’ensemble  des  fonctions  de  telle  sorte  que  tous 
les  rendez-vous  soient  tenus.  Ce  sont  les  contraintes  du 
temps-r6el.  Une  solution  possible,  d6pendante  du  temps 
d’ex6cution  de  chaque  fonction  (mat6rialis6  par  un  cr6- 
ncau  gris6),  est  d6cnte  dans  les  figures  ci-apr6s. 

(§  figure  4  planche  2  :  D6coupe  du  logiciel  durant  une 
p6riode  courte) 

Durant  cette  p6riodc  courte,  les  deux  fonctions  RE¬ 
CALAGE  et  PILOTAGE-RAPIDE  sont  ex6cut6cs  Tunc 
apr6s  Taube,  la  fonction  PILOTAGE-RAPIDE  n6cessi- 
tant  la  foumiture  d’unc  donn6e  de  RECALAGE. 

Sur  ce  graphique,  les  instants  d’enu6e  et  sortie  de  don- 
n6cs  extemes  sont  mai6rialis6es  par  les  pics  en  lecture  (r) 
et  en  6criture  (w). 

Durant  une  p6riode  longue,  6galc  dans  cet  exemple  h 
huit  p6riodes  courtes,  la  fonction  PILOTAGE-LENT  est 
r6alis6e. 

(§  figure  5  planche  2 :  D6coupe  du  logiciel  durant  une 
p6riode  longue) 

II  faut  noier  que  le  temps  d’ex6cution  de  cette  demibre 
fonction  a  permis  de  reffeciuer  en  deux  fragments  du¬ 
rant  la  premibre  pbriode  courte.  II  aurait  6t6  possible,  si 
nbcessaire,  de  la  segmenter  encore  pour  la  r^liser  sur 
plusicurs  pbnodes  courtes. 

L’exemple  dbcrii  lei  a  permis  de  citer  un  petit  bchan- 
tillon  de  conuaintes  b  prendre  en  compie  lots  de  la  rbali- 
sation  d’un  systbme  temps-rbcl.  II  nous  faut  maintenant 
aller  plus  loin  et  dberire  non  seulement  la  soluuon  obte- 
nue  mais  aussi  le  raisonnement  appliqub  par  I’expert 
pour  I’oblenir,  ce  qu’AGLAE  reproduit  automatique- 
ment. 


IV.  L’ ATELIER  LOGICIEL  AGLAE  : 

1.  Svstbme  expert : 

La  rbalisauon  d’un  systbme  expert  nbcessite  un  im¬ 
portant  invesiissement  (temps  et  cout).  Aussi,  pourquoi 
avons-nous  choisi  cette  solution  ? 

Les  raisons  sont  les  suivantes : 

-  rbussir  b  conserver  dans  I’entreprise  une  connaissance 
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et  un  savoir-faire.  Le  probl&me  est  d’autant  plus  aigil 
que  les  personnes  ddtenant  la  connaissance  sont  dans 
noire  cas  peu  nombreuses.  De  plus,  le  systbme  expert 
n’est  pas  un  stockage  passif  de  la  connaissance  mais  il 
est  constamment  remis  &  jour  et  enrichi, 

-  permetire  aux  experts  de  se  ddchaiger  des  tSchcs  r^pdti- 
tives  et  de  se  consacrer  it  d'autres  travaux, 

-  diminuer  les  coQts  de  mise  au  point  puis  de  maintenan¬ 
ce  d’une  application, ... 

Ccs  considerations  sont  trbs  gendrales  et  applicables  it 
tout  systbme  expert  Maintenant,  nous  pouvons  ajouter 
que  cette  methode  nous  permet  dans  le  cas  d’AGLAE  de 
rdsoudie  des  problbmes  fortement  combinatoires  (nom- 
bre  important  de  solutions  possibles)  et  dgalcmcnt  trbs 
contraints  (du  aux  contraintes  temps-rdel). 

D’un  point  de  vue  structure,  les  systbmes  experts  se 
caraetdrisent  par  leur  architecture.  A  la  difference  de  la 
progtammation  classique  qui  oppose  le  programme  aux 
donnees,  trois  composantes  sont  idcnufidcs  dans  un  sys- 
tfeme  expert ; 

-  la  base  de  fails, 

-  la  base  de  rbgles, 

-  le  moteur  d’mference. 

Une  quatrieme  composante  existc  ; 

-  I’interface  homme/machine  (§  chapiue  V  Resultats). 

Avant  de  dder  x  de  faton  prdcise  rimpldmentation 
d’AGLAE,  donnons  quelques  ddfiniuons ; 

-  la  base  de  fans  contient  I’ensemble  des  donndes  pro- 
pres  au  problfeme  ^  rdsoudre.  Cet  ensemble  dvolue  au 
cours  de  la  resolution  du  probldme  en  integrant  les  rd- 
suliats  iniermddiaires  et  la  ou  les  solutions  obicnues 
par  le  systdme.  La  base  peut  s’enrichir  en  cours  d’exd- 
cution  si  le  systdme  fait  appcl  5  I’utilisateur  pour  qu’il 
introdui.se  de  nouvelles  donndes. 

•  la  base  de  rdeles.  encore  appclde  base  de  connaissan- 
ces.  est  constitude  par  I'ensemble  des  mdthodes  de  re¬ 
solution  du  probldme  ddtermind.  Pour  communiquer 
ces  mdthodes  au  systdme,  I'expen  utilise  une  techni¬ 
que  de  representation  de  la  connaissance :  le  plus  sou- 
vent,  il  s’agira  de  rdgles  ou  productions  de  la  forme  • 

Si  conditions  Alors  actions 
La  base  de  connaissances  est  ainsi  constitude  d'un  en¬ 
semble  de  ces  entitds  dldmentaires :  les  rdgles.  Celles- 
ci  sont  declaratives,  elles  traduisent  le  savoir-faire  et 
I’expdrience  de  nos  experts  et  spdcialistes  du  domaine 
sans  prdjuger  de  leur  utilisation. 

-  le  moteur  d’infdrence  est  un  mdcanisme  gdndral  de  lai- 
sonnement  chargd  de  rdsoudre  le  probldme  spdcifid  par 
la  base  de  fails  d  I’aide  des  connaissances  contenues 
dans  la  base  de  rdgles.  Le  moteur  d’infdrence  est  un  lo- 
giciel  accessible,  ni  a  I’uulisateur  final,  ni  d  I’expert. 

A  partu’  de  ces  ddfinitions,  reprenons  chaque  module 
et  regardons  comment  il  a  dte  rda'isd  dans  AGLAE. 


2.  Base  de  fails : 

Dans  AGLAE,  la  base  de  fails  est  ddcomposde  en 
deux  sous-ensembles ; 

-  tout  d’abord,  une  base  de  faits  oronres  au  probldme  d 
rdsoudre.  comme  ddcrite  prdeddemment,  reprenant  la 
description  de  la  Spdcification  Fonctionnelle  Technique 
(mission  et  contraintes  du  systdme), 

-  puis,  la  base  de  faits  permanents,  ou  encore  ^pelde 
base  de  donndes.  comprenant  toutes  les  caraetdnstiques 
techniques  et  commerciales  des  matdriels  utilisables 
(composants  du  marchd,  composants  militarisds, ...). 

2. 1 .  Spdcification  Fonctionnelle  Technique : 

2.1.1.  Pratique  des  experts : 

Les  experts  distingucnt  deux  types  d’objets,  les 
functions  et  les  donndes ; 

-  les  fonctioiis.  encore  appcides  Machines  Abstraites 
(MA),  reprdsentent  soil  des  dldments  matdriels,  soil 
des  dldments  logiciels  du  futur  systdme, 

-  les  donndes  forment  I’ensemble  des  communications 
vuiuclles  ou  rdelles  entre  les  functions.  Une  donnde  est 
produite  pour  une  unique  fonction  mais  peut  due  con- 
sommde  par  plusieurs. 

A  chaque  donnde  sont  associdcs  des  informations  Utiles 
que  les  fonciions  qu’ellc  relie,  sa  prdcision, ... 

A  chaque  foncuon  sont  associdcs  plusieurs  informations, 
telles  que  son  enude  (donndes  consommdes),  sa  sortie 
(donntes  produitcs),  le  traitement  qu’elle  rdalise,  sa  frd- 
quence,  son  temps  d’exdcution,  sa  prdcision, ... 

Maintenant,  les  donndes  et  les  functions  dnonedes  ici,  ne 
suffisent  pas  it  dderue  toutes  les  conuaintes  dues  au 
tcmps-rdel.  Comme  nous  I’avons  vu  sur  I’exemple  prd- 
eddeni,  il  faut  aussi  ddcrire,  d  partir  de  la  spdcification, 
des  coupleurs  d’enude-sorue  qui,  d  chaque  pdriode,  re¬ 
prdsentent  des  fendues  ouvertes  d  un  certain  moment 
pendant  une  certainc  durde. 

Ccs  fendues  imposent  que  les  fonctions  qui  produiscnt 
ou  consommeni  ces  donndes  soient  exdcutdes  (pour  faire 
Icurs  emrdcs  et  sorties  au  moms)  pendant  la  durde  de  ces 
fcncu’es. 

Ces  fonctions  seront  reprdsentdes  dans  AGLAE  comme 
des  machines  absuailes,  mais  avee  des  caraetdnstiques 
suppidmenuiires  telles  que  les  dates  de  ddbut  et  de  fin  de 
production,  les  dates  de  ddbut  et  de  fin  de  consommation 
de  donndes. 

2. 1 .2.  Moddlisation  dans  AGLAE  : 

L’ ensemble  de  la  Spdcification  Fonctionnelle 
Technique  est,  comme  nous  venons  de  le  voir,  composdc 
uniquemcnt  de  fonctions  et  de  donndes.  Ces  deux  dld- 
ments  sont  considdrds  dans  AGLAE  comme  des  objets  ^ 
part  enudrc  et  matdrialisds  par  des  schdmas  compatibles 
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avec  le  formalismc  du  gdndrateur  utilisd. 

Pour  les  fonctions,  un  ensemble  de  machines  absuaiies 
(MA)  est  crdd.  Chaque  MA  est  une  insiance  d’un  objei 
de  la  base  de  fails  el  est  d^crite  sous  la  forme  suivante : 

Schema  PHASE- VOL 

instance  machine-scqu  (pour  machine  ddcomposable) 
ddcomtx)sition-en  EOTREE-0  ENTREE- 1 

PILOTAGE  RECALAGE  SORTlE-0 
est-un-comoos^-de  (nom  de  la  maehine  parent) 
unitd-temps  ms 
nbre-unitd/s  1000 
entrfe  (pour  donntes  en  entrdc) 
sortie  (pour  donndes  en  sortie) 


Une  des  machines  la  composant  est  RECALAGE : 
Schdma  RECALAGE 

insiance  machine-base  (pour  machine  absiraite) 
est-un-comnosd-de  PHASE-VOL 
tcmos-exdcution-maxinium  10  (pour  10  ms) 
entrtefSOUS-CYCLE-1  0)  (SOUS-CYCLE-I  -1) 
sortie  (POS-MACH  0)  (ACC-COMM  0) 

(SORTIE- 1 -COMM  0) 

(0  pour  standard,  -1  pour  asservisscmcni) 
frdouence  60  (en  Hertz) 

Une  des  donndcs  produitc  par  RECALAGE  est  POS- 
MACH: 

Schema  POS-MACH 
instance  paqucts-donnees 
prod-paouet  RECALAGE  (fonciion  productrice) 
cons-paauet  PILOTAGE-LENT 

(fonction  consommairicc) 

Tous  ces  objets  sont  rdunis  dans  des  fichiers  inodifiables 
par  ruiilisaieur,  soil  do  fa^on  textuclle  (tfdiicur  ASCII), 
soil  sous  forme  graphiquc  (interface  sp&ifique). 

2.2.  Base  de  donndcs  Matdriel : 

2.2.1.  Pratique  des  experts : 

Le  second  sous-ensemblc  composant  la  ba.se  de 
fails  est  chargd  de  ddtenir  I'enscmblc  des  informations 
matdriellcs. 

11  s’agit  h  la  fois : 

-  des  types  d'architectures,  mono  et  multi  processeurs, 
simples  et  complexes  avec  m6moircs  coupldcs,  DM  A^,, 
1  a  N  bus  extemes, ... 

Celles-ci  ont  &\&  rcccnsdes  parmi  les  architectures  les 
plus  commundment  uiilis6es  dans  I’enucprise  mais 
aussi  parmi  cclles  connucs  S  ce  jour. 

-  des  difKrcnis  composants  maidricls  (bus,  processeurs. 


mdmoires,  coupleurs, ...).  Ces  composants  sont,  ou 
bicn  spdcifiques  (ddveloppds  en  interne  &  aerospa- 
tiale,  ou  bicn  du  commerce).  Dans  ce  dernier  cas,  tou- 
tcs  les  informations  sont  acccssibles  h  partir  des 
documentations  des  divers  foumisscurs. 

2.2.2.  Moddlisation  dans  AGLAE : 

De  la  mSme  faqon  que  la  base  de  fails  relative  ^ 
la  specification,  les  diffdrentes  architectures  et  compo¬ 
sants  sont  entres  dans  AGLAE  sous  la  forme  d’objcts. 
Parexemplc,  rarchitccturc  ARCHI-MONO-COUPLEE 
(architecture  mono-processcur  avec  mdmoires  coupldes) 
sc  prescnie  sous  la  forme  d’un  schema : 

Schema  ARCHI-MONO-COUPLEE 
mono-processcur 

processeur  (nombre  de  processeurs) 

bus-interne  (nombre  de  bus) 

memoire-donnee  (nombre  de  memoircs  de  donnees) 

memoirc-programme  (nc.nbrc  de  memoircs  de  code) 

uansfert-donnees-int 

(pour  temps  de  tfansfert  des  donnees  en  interne) 
transfert-programme  (temps  de  transfert  du  code) 
maioration-acefcs-memoire  (temps  acefcs  memoire 
cslime  s’ll  n’est  pas  connu  exactcmcni) 

Quant  aux  matericis,  la  description  d’un  processeur  sc 
fail  de  la  fa^on  suivante : 

Schema  PROCESSEUR-X 

is-a  processeur  (appartient  b  la  classc  des  processeurs) 
frepucncc  1E6  (pour  1  Mega-Hcrtz) 

+  4  (I’operation  addition  dure  4  cycles  de  base) 

,..  (temps  rcspcciifs  pour  les  aulres  operations) 
coproccs.scur  (lisle  des  coproccsscurs  associes) 

...  (liste  dcs  autres  composants  associes) 

Pour  les  autres  composants,  les  caracterisliques  propres 
sont  inscriies  sous  la  forme  de  proprieies  relatives  5 1’ob- 
jet  decrit. 


Globalcmcnt,  tous  les  objets  composant  les  deux 
sous-cnsembles  de  la  base  de  fails  sont  rdums  dans  une 
structure  arboresccnie  comprenani,  a  partir  d’une  racine, 
differenics  classes: 

-  la  classe  RACINE-M.ATERIEL  ou  base  de  donnees 
Materiel  consiituee  de  I’enscmblc  des  types  d’architectu- 
rcs  et  dcs  composants  matericis, 

-  la  classc  RACINE-LOGICIEL  decrivant  la  Specifica¬ 
tion  Fonctionnelle  Technique  composec  des  machines 
absu’aiies  et  des  donnees, 

-  la  classe  R  ACINE-SOLUTION  ou  sont  crees,  durant  la 
resolution,  les  objets  iclatifs  aux  solutions  proposees 
(materiel  et  logiciel). 

(§  figure  6  planche  3) 


3.  DMA  :  Direcl  Access  Memory  ou  Acccs  direci  a 
la  memoire. 
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3.  Base  de  connaissances : 

Si  ie  moteur  d’inKrence  (§  paragraphe  4  Moteur  d’in- 
fdrence)  reprdsente  “I’intelligence”  d’AGLAE,  les  rfe- 
glcs,  dies,  rcprisenicm  son  unique  “connaissance". 
Exnaites  de  I’expdrience  des  expens  et  spdcialistes  du 
domaine,  dies  permettent  au  syst&mc  de  trouver,  par  ite¬ 
rations  successives  la  solution  rechcrchde. 

Elies  sont  formalisdes  de  la  fa?on  suivante : 

Si  conditions  Alors  actions 

Aujourd’hui  AGLAE  contient  onze  classes  do  rtgles ; 

-  architecture ;  choix  d’une  architecture  matdridle  en 
fonction  des  contraintes  do  la  sp&;irication, 

-  comoosants :  compidtion  de  I’architecturc  matdrielle 
choisie  grke  ^  la  base  de  donndos  des  composants, 

-  durde :  calcul  du  temps  d’exdcution  de  toutes  les  fonc- 
tions  it  panir  de  la  durde  des  opdrations  dldmentaires 
du  processeur  choisi, 

•  co^ :  respect  du  seuil  imposd  par  rulihsateur  concer- 
nant  Ie  calcul  du  cout  des  composants  choisis, 

•  chemins ;  recherche  des  chemins  de  donndes  prioritai- 
res, 

•  communications :  erdation  des  machines  abstraites  de 
communications  sur  tous  les  chemins  de  donndes, 

-  sdouencialisation :  erdation  d’une  chaine  temporellc  re- 
groupant  I’enscmblc  des  machines  abstraites, 

-  datation ;  calcul  des  temps  relatifs  it  chaque  fonction 
dans  la  chatne  temporellc, 

-  ddeounage :  segmentation  des  fonctions  Icntcs  sur  plu- 
sicurs  pdriodes  courtes, 

-  ddnlacement ;  cn  cas  d’dchec,  on  cffectue  une  modifi¬ 
cation  de  remplaceincnt  d'unc  fonction  dans  la  chaine 
temporellc, 

-  ddnhasage :  cn  cas  d’dchec,  les  fonctions  nc  pouvant 
ctre  exdcutdes  dans  la  pdriode  impartie  devront  accep¬ 
ter  les  donndes  de  la  pdnode  prdeddente. 

Par  exemple,  nous  aurons ; 

Une  rdgle  de  eestion  temoorelle  des  ressources : 

Si  deux  machines  absnaitcs  ont  des  frdqucnces  diffd- 
rentes, 

Alors  la  machine  abstraitc  de  frdquence  la  plus  rapide 
cst  prioritairc. 

ou  encore  une  rdgle  de  regrouixiinent : 

Si  deux  machines  absuaitcs  ont  la  mcme  frdtiuence  ct 
que  I’une  proJuit  des  donndes  exclusivemcnt  pour 


I’aulre, 

Alors  erder  une  machine  absu-aite  les  regroupant. 


4.  Moteur  d’infdrence : 

4.1.  Principe : 

Pour  AGLAE,  un  moteur  d’infdrence  spdcifique  a 
dtd  construit. 

Les  systdmes  fonctionnant  cn  chainage  arridre  (comme 
PROLOG)  sont  inaddquats  pour  Ie  genre  de  prdbldmes 
traitds  par  AGLAE  (construction  ou  synthdse). 

Les  systdmes  classiques  en  chainage  avant  (comme 
OPS)  sont  peu  efficaces  et  posent  de  nombreux  probld- 
mes  lids  d  la  non-monotonie  (une  rdgle  peut  ddtruire  un 
fait  sur  Icquel  reposent  d’autres  faits). 

Les  probldmcs  de  construction  dtant  des  probldmes  dans 
Icsqucls  les  choix  sont  nombreux,  il  cst  plus  aisd  de  tra- 
vaillcr  sur  des  contextes  sdpards  (un  par  choix)  et  de 
maintenir,  d’un  contexte  pdre  d  ses  fils,  la  cohdrcncc  des 
informations  au  moycn  d’un  programme  spdeial ;  un 

rMSl 

Or,  la  complexitd  d’  une  tdchc  de  rdsolu'*  de  probldmcs 
cst  fonction,  d  la  fois  du  nombre  de  rd  jles  cxc^aides,  ct 
du  nombre  de  contextes  considdrds  dans  la  recherche. 

L’unc  dcs  premidres  raisons  qui  a  moUvd  la  construction 
d’un  nouveau  moteur  pour  AGLAE  a  dtd  la  ndccssitd  de 
spdeifier  Ie  contrdle  du  besoin  cxpnmd  par  I’ordre  de  dd- 
clcnchcment  dcs  rdglcs,  et  exprimant  Ic  raisonnement 
dcs  experts.  Un  tel  contrdle,  rdalisd  par  un  programme 
procddural  classique,  diminue  la  flexibilitd  de  I’outil  ct 
complique  sa  maintenance. 

Dans  AGLAE,  le  contrdlc  est  iraduit  par  la  rdunion  de 
ccrtaincs  rdglcs  en  classes  (sources  de  connaissances),  ct 
par  I’utilisation  de  mdla-rdgles  pour  le  choix  de  ccs  sour¬ 
ces  de  connaissances  dans  un  contexte  donnd. 

Les  contextes  ferment  ainsi  un  graphe  (arbre)  qui  est  ex- 
plord  s'livant  une  proeddure  BRANCH  AND  BOUND 
gdndralisde  (GBB*).  Cellc-ci  incorpore  h  la  fois  I’utilisa- 
tion : 

-  d’un  ordre  de  prdfdrcncc  sur  les  sources  de  connaissan- 
ccs  ct  les  rdglcs, 

-  d’un  “backpacking”  intelligent  (DDB^), 

-  d’un  ATMS^  pour  maintenir  la  cohdrcnce  de  chaque 
contexte. 

En  effet,  un  rdsolvcur  de  probldme  conuold  par  DDB  a 
tendance  d  ctre  plus  cfficace  pour  dcs  probldmes  dans 
Icsqucls  quciques  solutions  parmi  toutes  cellcs  possibles 
sont  ddsirccs.  L’efficacitd  est  obtenue  en  organisant  la  re¬ 
cherche,  de  manidre  d  ne  pouver  qu’une  solution  spdcifi- 
que  d’abord.  La  combinaison  d’un  ATMS  et  de  DDB,  d 
la  fois,  rdduit  le  nombre  de  contextes  exainmds  et  de  rd- 
glcs  exdcutdes.  et  pcmict  d’obtenir  efficacement  une  so¬ 
lution  spdcifique  en  premier. 


4.  TMS  :  Truth  Mainlcnancc  System 

5.  GBB  :  Generalized  Branch  and  Bound 

6.  DDB  :  Dependency  Directed  Backpacking 

V.  ATMS  .  Assuinplion  Truth  Mainlenance  System 
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Quand  une  contradiction  est  rencontrde,  le  retour  (back¬ 
tracking)  est  effectud  jusqu’au  premier  “gdndrateur” 
contribuant  ^  la  contradiction  (c'est-^-dire  la  gdndration 
de  la  premibre  cause  d’dchec).  Toutes  les  raisons  pour 
dliminer  des  valeurs  sont  combindes  pour  former  une 
contradiction.  Mais  le  systdme  ne  se  souvient  pas  de  ces 
contradictions  quand  une  autre  bianche  est  trouvde.  Cer- 
taines  d'enue  elles  peuvent  done  dtre  caiculdes  piusieurs 
fois  de  suite.  Dans  AGLAE,  chaque  cause  d’erreur  (con- 
jonction  minimale)  est  retenue  de  manibre  permanente 
pendant  la  recherche. 

4.2.  Moddlisation  dans  AGLAE : 

En  s'appuyant  sur  I'algorithme  prdeddent, 
AGLAE,  b  partir  de  la  spdcification  fonctionnelle,  doit 
commencer  par  construire  un  sy  stbme  fonctionnellcment 
dquivalcnt.  L'aichitecture  matdricile  est,  soit  ccllc  qui  cst 
imposde,  soit  la  plus  simple  possible.  L'organisation  lo- 
giciellc  correspond  exactement  b  la  spdcification  :  pas 
d'interruptions,  exdcution  des  tbches  entibrement  sd- 
quentielle.  Si,  aprbs  simulation,  le  rdsultat  est  acceptable 
scion  les  contraintes  tcmporellcs,  il  cst  proposd.  • 

Dans  le  cas  contrairc,  cettc  architecture  constitue  alors  la 
racinc  de  I'arbre  des  solutions.  Les  uansformations  entre 
un  nocud  pbre  et  ses  fils  rdsident  dans  l'organisation  tem- 
porelle  des  tbches  et  la  suppression  ou  I'ajout  dvcntuci 
de  composants  matdnels. 

La  rdorganisation  temporelle  sc  fait  par  ddcoupage  ct  re- 
groupement  des  sous-fbnetions  de  la  spdcification,  le  but 
final  dtant  de : 

-  respecter  les  retards  sur  les  donndes, 

■  diminuer  le  temps  global  de  calcul. 

Tout  nccud  est  alors  testd  comme  une  solution  dvcntucllc 
du  s>stbme.  En  cas  d'dchcc,  on  isole  la  cause  minimale 
de  I'dchec  et  on  supprime  tous  les  nocuds  de  I'arbre  vdri- 
fiant  cette  cause. 

Si  aucune  des  organisations  cssaydes  no  satisfait  I’cn- 
semble  des  contraintes,  une  auue  architecture  matdriellc 
est  recherchde,  ou  ur.v  modification  des  frdqucnces  est 
imposde. 


V.  RESULTATS  : 

Les  figures  ci-aprbs  montrent  pour  I'exemple  ddcrit 
au  ddbut  du  document,  la  solution  proposde  par  AGLAE. 
On  retrouve  siu  la  planche  4,  la  Spdcificauon  Fonction¬ 
nelle  Technique  sous  forme  graphique. 

Puis,  sur  cette  mbme  planche,  les  chronogrammes  rdsul- 
tats  sur  une  pdriode  courte  et  une  pdriode  longue. 

En  plus  des  functions,  dont  I'cxdcution  est  matdrialisde 
par  des  erdneaux,  les  chronogrammes  inoiquent : 

•  le  nom  des  fonctions  de  communications  erddes, 

-  I'instant  ou  dies  sont  utilisdes  a  des  fins  de  rndmorLsa- 


tion  de  donndes  (en  dcriture  ou  en  lecture), 

-  les  fonctions  de  gestion  de  contextes  permettant  la  sau- 
vegarde  et  la  restauration  de  I'environnement  lots  d’in- 
temiptions  ou  de  reprises  de  fonctions  lentes. 

La  demibre  planche  indique  I'ensemble  des  composants 
choisis,  leur  coQt,  I'architecture  matdrielle  adt^tte  ainsi 
que  le  rdsultat  complet  de  la  simulation  du  systbme  avec, 
pour  la  tachc  rapide  (pdriode  courte)  et  la  tbche  lente  (pd¬ 
riode  longue)  : 

-  le  temps  total  d'cxdcution, 

-  le  temps  total  de  communications  interne  et  exteme, 

-  le  temps  total  de  gestion  des  contextes, 

-  le  taux  de  charge  du  processeur  choisi. 

II  faut  noter  que  cette  demibre  information  est  primor- 
dialc  pour  le  conceptcur,  car  ellc  le  renseigne  sur  les  li- 
mites  du  systbme  en  ce  qui  conceme  les  modifications  de 
maintenance  (possibilitd  d'augmentation  de  la  taille  des 
logiciels,  de  la  vitesse  des  processcurs,  du  changement 
de  composants, ...). 

Tous  ces  rdsultats  sont  prdsentds  sur  Tdcran  AGLAE. 
Afin  de  raster  le  plus  convivial  po.ssible,  aucune  com- 
mandc  n'est  enude  sous  forme  tcxtuclle.  Toute  demandc 
de  traitement  se  rdalise  grbee  b  la  souris  cn  “cliquant”  sur 
une  icone  b  droitc  de  I'dcran. 

Six  icones  sont  reprdsentdes : 

-  la  prcmibtc  permet  I'affichage  d'un  texte  de  prdsenta- 
lion  du  logiciel, 

-GEST  pour  Gestion 

*  LOAD :  chargemcni  d'une  spdcification, 

*  SAVE  :  sauvegardc  sur  di.sque  d'une  spdcification, 

*  CHECK :  vdrification  syniaxique  ct  sdmantique 
d'une  spdcification, 

*  KILL :  effacement  d’une  spdcification  en  mdmoire, 

*  RUN :  rdsolution  et  recherche  de  solutions, 

»  QUIT:  sortie  d’AGLAE. 

-  VIEW  pour  fonctioas  de  Visualisation 

*  OV^VIEW :  spdcification  complbtc  sur  la  page 
dcran, 

*  ZOOM  :  vue  limiide  d’une  partie  de  la  .spdcification 
avec  ddplacemcnis  grbee  b  des  ascenseurs  verticaux 
ct  horizontaux  le  long  de  la  feneue  de  visualisation, 

*  TRAME  :  Tranie  de  fond  ou  dcran  d’attenie. 

-  EDIT  pour  Edition  de  la  base  de  donndes 

*  EDIT :  ddition  des  objets  stockds  dans  AGLAE, 

*  TREE :  visualisation  des  objets  et  des  classes  sous  la 
forme  d’arbres. 

-  GRAPH  pour  dditeur  Graphique  de  la  spdcification 

*  COMPOSE :  erde  des  fonctions  ddcomposables, 

‘  FUNCTION :  erde  une  machine  abstraite  de  base, 

*  WINDOW :  erde  une  fenetre  d’entrde-sortie, 

*  DATA  :  erde  une  donndc, 

*  ARCHITECH'URE :  erde  I’objet  descripteur  de  I’ar- 
chiicclure  choisic  si  elle  existe. 


8-10 


*  DELETE :  pennet  d’effacer  une  bolte  ou  une  don- 
nte, 

*  MOVE :  permet  de  d^placer  une  boite  ou  une  donndc 
sur  r&ran. 

-  LASER  pour  impression  sur  un  pdriphdriquc  cxteme 

*  ECRAN :  image  dcran  en  formal  POSCRIPT, 

*  SOLUTION :  texte  associd  ^  la  resolution  avcc  pro¬ 
positions  de  solutions, 

*  ECHEC :  texte  associd  au  refus  de  solutions  avec  le 
diagnostic  prononc^. 


VI.  CONCLUSION: 

1.  Validation : 

Plusicurs  systdmes  opdrationnels  sent  utilises  pour  la 
validation  des  connaissanccs  contcnucs  dans  AGLAE, 
ccci  dans  le  but  de  vdrifier : 

-  qu’avcc  la  scule  desciiption  de  la  Specification  Fonc- 
tionnellc  Technique,  AGLAE  cst  ^  mfime  de  proposer 
une  voire  plusicurs  soluuons, 

-  qu'avcc  un  mSme  choix  de  composanis,  Ics  solutions 
proposees  sont  similaires  i  ccllcs  retenues  par  Ics  con- 
ccpteiirs  humains. 

II  cst  important  do  preciscr  que  ces  solutions  sont  obte- 
nucs  en  quelques  minutes  (aprds  I’entrec  des  donnecs), 
alors  que  reiaboration  et  la  validation  d'unc  autre  solu¬ 
tion  prenaiiauparavcnt  plusicurs  jours  aux  ingenicurs. 

2.  Evolutions : 

AGLAE  est  dcrit  en  Common  LISP  ct  s'appuic  sur  le 
generatcur  de  sysiemc  expert  KNOWLEDGE 
CRAFF”*  V3.3.  Les  objels  sont  dcs  schemas  CRL^”’, 
tandis  que  les  autres  connaissanccs  (rdgles)  ct  le  motcur 
d’infercnce  sont  dcs  fonciions  de  Common  LISP. 

Le  materiel  utilise  est  un  SUN  3/260’^“’®  sous  cnviron- 
ncmentUNIXTNV4.0.3'‘. 

Malgrd  les  quelques  1 10  objets  rdpartis  dans  Ics  bases 
de  fails,  et  les  1 1  grands  sous-cnscmbles  de  rdgles  de  la 
base  de  connaissanccs,  AGLAE  cst  encore  loin  de  rdsou- 
dre  tous  les  problJmes  temps-recl  renconues  dans  nouc 
Division. 

Les  evolutions  prochaines  du  produii  permcitroni  par 
exemple  : 

-  I’cnrichissement  de  la  base  de  donnecs  pour  prendre  en 
compte  un  nombre  plus  important  de  composanis  du 
marche  et  de  nouvelles  architectures, 

-  I’enrichissement  de  la  base  de  connaissanccs  pour  of- 


8.  KNOWLEDGE  CRAFT  esi  une  marque  deposec 
par  CARNEGIE  GROUP  INC. 

9.  CRL :  CARNEGIE  Representaiion  Language  est 
une  marque  deposCe  par  CARNEGIE  GROUP  INC. 

10.  SUN  est  uiie  marque  deposCe  par  SUN  MICRO¬ 
SYSTEMS. 

11.  UNIX  est  une  marque  deposde  par  AT&T  BELL 
LABORATORIES. 


frir  des  solutions  &  base  de  multi-processeurs.  Ceci  im- 
plique  I’analy'  J  fine  des  differents  paralieiismes 
possibles  (etuae  des  grains), 

-  le  couplagc  avec  des  ateliers  de  G6nie  Logiciel  du  com¬ 
merce  qui  permeura  de  couvtir  I’ensemble  des  phases 
du  cycle  de  vie  d’un  systfeme  notamment : 

*  la  phase  de  codage  du  logiciel  (ADA,  C, ...), 

*  la  phase  de  test  automatique  du  logiciel  codd, 

*  la  phase  de  documentation  sous  des  formats  notmali- 
s6s  lels  que  AQAP  13,  GAM  T17,  DoD  2167B, ... 

Quant  ^  la  phase  de  specification,  une  etude  est  en 
cours  afin  de  facilitcr  le  travail  du  concepteur  humain. 
En  effet,  AGLAE  devta  lui-mcmc  afficher  la  Specifica¬ 
tion  Fonctionnelle  Technique  sous  forme  graphique,  S 
partir  d’un  texte  en  langagc  naturel,  ceci  pour  limiter  au 
maximum  Ics  manipulations  d'editcurs  toujours  fasti- 
dieuscs  pour  I’utilisateur  final. 

Enfin,  un  portage  en  langagc  C-h-  cst  envisage  avcc 
un  generatcur  d’interface.>  suffisamment  normalise  pour 
envisager  une  utilisation  de  I’atclicr  AGLAE  sur  des  ty¬ 
pes  de  console  et  d’cnvironnemeni  quelconqucs. 
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Figure  6  :  Structure  arboiescente 
de  la  base  de  faits 
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Summary 

Within  this  paper  we  present  some 
basic  concepts  of  the  software  design 
for  a  command  and  control  workstation 
for  airborne  applications.  We  report 
not  only  on  theoretical  considerations 
but  also  on  practical  experience, 
which  was  gained  during  the 
development  process  of  a  prototype 
command  and  control  workstation  at 
DORNIER.  Special  emphasis  is  put  on 
software  archtitecture,  data 
structures  and  tasking  with  respect  to 
Ada.  In  order  to  get  a  firm  basis  and 
to  ease  understanding  the  paper  starts 
with  a  description  or  the  tasks  and 
components  of  a  command  and  control 
workstation,  which  includes  a  short 
description  of  the  afore  mentioned 
DORNIER  prototype  workstation  MODOS, 
The  paper  concludes  with  some  Issues 
on  software  "-ilitles". 


1.  Introduction 

Airborne  command  and  control  (C^) 
workstations  will  be  used  in  a  variety 
of  different  applications,  will  range 
from  maritime  patrol  to  border  patrol, 
from  military  missions  to  civil 
missions,  and  include  different  flying 
latforms,  i.e.  aircrafts  as  well  as 
ellcopters . 

A  workstation  operates  as  a  link 
between  a  human  operator  and  an 
environment  (fig.  1),  which  normally 
consists  of  a  suite  of  sensors  and  In 
some  cases  also  of  effectors^ 
Basically,  employment  of  a 
workstation  may  be  as  a  stand-alone 
unit  connected  to  a  single  sensor,  or 
in  a  more  effective  way  as  a  single 
station  controlling  multiple 
sensors/effectors,  or  within  a  network 
of  multiple  sensors/effectors  and 
workstations,  which  in  addition 
rovides  the  ability  of  a  redundant 
esign  of  the  system. 

2.  0^  Workstation  Description 

2.1  Capabilities 

The  following  main  capabilities  have 
to  be  provided  by  a  C  workstation 

-  man/machine  interface 

-  sensor /effector  management  and 
sensor  data  acquisition 

-  data  processing 

-  data  storage 

These  capabilities  will  be  used  for 
applications  as  for  example 


-  antisubmarine  warfare  (ASW) 

-  signal  intelligence  (SIGINT) 

-  search  and  rescue  (SAR) 

-  pollution  control 

-  coast  guard 

-  fishery  patrol 

-  photogrammetry 

-  verification 

Fig.  2  shows  the  environment  for  an 
ASw  mission,  certainly  requiring  more 
than  one  workstation,  whilst  the 
pollution  control  example  in  fig.  3 
may  well  manage  with  a  single  station. 

2.2  Components 

From  a  system  point  of  view  a 
workstation  consists  of  a  multitude  of 
arts,  from  a  software  point  of  view 
owever  there  are  only  a  few 
components,  that  have  to  be  mentioned 
(fig.  <1).  These  components  which  host 
the  software  or  work  together  with  the 
software  are  as  follows 

-  the  workstation  processor  (main 
processor) , 

the  heart  of  the  workstation 

-  the  workstation  add-on  processors, 
additional  or  specialized  processing 
power 

-  the  graphic  engine  with  one  or  more 
display  screens, 

output  generation  and  presentation 
to  the  operator 

-  the  operator  input  devices, 

the  means  of  human  input  interaction 

-  the  system  interfaces, 

the  various  connections  to  the 
outside  world 

It  is  obvious  that  a  modular  design 
will  ease  workstation  adaption  to 
special  needs. 

2.3  MODOS 

For  the  afore  mentioned  tasks  DORNIER 
have  developed  a  workstation  based  on 
a  set  of  requirements  of  which 
modularity  was  one  of  the  most 
Important.  Therefore  the  name  of  that 
station  was  chosen  as  MODOS  standing 
for  MODular  Operator  Station.  The 
workstation  shown  in  fig.  5  is 
installed  into  a  Do228  aircraft,  which 
acts  as  a  small  maritime  patrol 
aircraft,  equipped  with  a 
SUPERSEARCHER  radar,  a  KESTREL  ESM  and 
a  secondary  LINS  navigation  system. 

The  software  of  this  system  and  the 
experience  gathered  during  the  course 
of  its  development  is  subject  and 
basis  of  the  following  design 
considerations. 
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3.  Software  Design  Considerations 

A  command  and  control  workstation  i*!  a 
real-time  embedded  computer  system 
because  of  its  connection  to  a  real¬ 
time  process,  real-time  information 
gathering  and  processing,  and 
immediate  interaction.  Although  not 
extremely  demanding,  we  have  to  tackle 
with  interrupts,  concurrency, 
multiprocessing  and  time  dependency.  A 
well  structured  software  may  help  to 
meet  these  challenges. 

3.1  Architecture 

As  explained  before  one  of  our  most 
stringent  requirements  was  modularity 
in  hardware  and  software,  because 
modularity  is  seen  as  the  key  to 
flexibility  and  adaptability. 
Modularity  should  also  help  to  build 
up  an  open  archtitecture  (fig.  6).  The 
first  step  in  this  direction  is  the 
separation  between  application 
dependent  software  and  application 
independent  software.  In  this  way  we 
introduce  some  kind  of  structuring, 
which  is  of  course  reasonable,  but  it 
is  merely  suitable  for  an  overview.  In 
order  to  get  a  useful  architecture,  we 
have  to  get  a  deeper, insight  into  the 
functionality  of  a  workstation. 

Starting  with  the  context  diagram  of 
fig.  7a  as  the  first  level  we  achieve 
by  means  of  usual  stepwise 
decomposition  on  the  second  level  what 
we  call  platforms  (fig.  7b)  and  on  the 
third  level  what  we  call  building 
blocks  (fig.  7c).  A  group  of  building 
blocks  forms  a  platform.  As  indicated 
in  fig.  7b  we  distinguish  a  man- 
machine  platform,  a  sensor  platform,  a 
data  storage  platform,  and  a  special 
processing  platform.  Fig.  7c  gives 
more  detail  by  showing  the  building 
blocks  of  the  man-machine  platform, 
including  the  operator  input/output 
devices . 

3.2  Standards 

Another  design  goal  was  to  rely  on 
standards  whenever  possible.  Where 
formal  standards  were  not  available  we 
applied  quasi-standards,  i.e.  widely 
used  conventions  or  agreements  (table 
1). 


we  adopted  the  military  standard  to 
the  civil  product. 

ARTX,  the  real-time  executive,  is  the 
operating  system  which  is  used  for  our 
workstation  in  conjunction  with  Ada. 
ARTX  is  widely  accepted  in  industry, 
it  is  a  quasi-standard. 

GKS  stands  for  Graphical  Kernel 
System,  it  is  one  of  several  graphic 
standards  in  use.  We  use  GKS  level  2C 
with  standardized  Ada  language 
binding . 

The  symbol  set  to  generate  tactical 
situation  presentations  is  adopted 
from  the  German  Navy.  The  symbol  set 
is  realized  as  a  data  structure  and  is 
therefore  easily  interchangeable. 

IPX  as  an  amendment  to  ARTX  is  the 
file  handling  system.  It  provides  a 
MS-DOS-like  rile  structure,  which  is 
also  regarded  as  a  quasi-standard. 

We  have  applied  no  database  standard, 
no  library  standard  and  no 
presentation  standard,  mainly  because 
relevant  standards  were  not  available 
when  we  started  our  development.  A 
math  library  standard  as  NAG  (Numeric 
Algorithm  Group)  or  AGL  (Ada  Generic 
Library)  was  not  necessary  and  not 
applicable  resp.  Maybe  we  will  use  SQL 
or  X-Window  in  the  future. 

3.3  Data  strucures 

Data  flow  and  data  structures  are  also 
areas  which  have  to  be  considered 
during  software  design.  Whilst  data 
flow  16  more  a  global  matter  to  be 
examined  during  the  analysis  phases, 
data  structures  have  to  be  determined 
during  the  software  design  steps. 

Generally  we  have  to  deal  with  two 
kinds  of  data  flows 

o  sensor  ->  processing  ->  presentation 

or 

->  storage 

o  operator  ->  processing  ->  sensor 

or 

->  presen¬ 
tation 
or 

->  storage 


Table  1:  SW-Standards  &  Quasi- 
Standards 


-  Programming  Language 

-  Operating  System 

-  Graphics 

-  Symbol  Set 

-  Files 

-  Data  Base 

-  Libraries 

-  Presentation 


Ada 

ARTX 

GKS 

national 

IPX 

SQL 

NAG 

X-Wlndow 


whereat  the  second  flow  is  mainly  a 
control  flow,  only  sometimes  combined 
with  data. 

One  of  the  problems  that  arise  when 
developing  a  software  structure  are 
the  synchronous  and  asynchronous 
aspects  of  the  environment,  i.e.  we 
have  to  handle 

synchronous /asynchronous  input  and 
output . 


Ada  as  a  programming  language  standard 
is  of  course  the  most  significant 
standard  for  this  project.  Ada  is  now 
a  "must"  in  the  military  market-place, 
but  the  benefits  of  Ada  are  also 
attractive  for  the  civilian  area.  And 
because  we  want  to  serve  both  markets 


Asynchronous  input  means  that  the  time 
when  data  input  occurs  cannot  be 
predicted.  For  example  all  operator 
input  is  asynchronous.  Also  some 
sensor  types  are  designed  to  deliver 
data  only  by  event,  because  for 
embedded  computer  systems  often 


% 

i 
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interrupts  are  used  to  decrease  CPU 
overhead. 


operator  inputs.  In  other  words  one 
has  to  establish  a  tasking  concept. 


Asynchronous  output  is  output  of  which 
the  amount  of  generated  data  is 
variable.-  As  a  result  the  time  needed 
to  generate  these  data  is  variable. 

For  example  the  amount  of  graphic 
output  data  depends  on  the  number  of 
objects  to  be  displayed  or  refreshed.. 
Output  data  generated  only  when  a 
certain  event  occurs  is  also 
asynchronous  (e.g.  operator  action  to 
provide  effector  data).. 


Our  MODOS  software  design  comprises 
38  tasks,  a  fairly  high  number,  and  it 
has  to  be  explained  which 
considerations  led  to  this  number.  To 
begin  with,  these  tasks  may  be  sorted 
into  3  categories,  which  are  shown  in 
table  2. 

Table  2:  Task  classification 
Type  Qty  Characteristics 


Synchronous  input  is  data  received  Actor 

with  a  constant  frequency  and  constant  Task 
data  block  size.  Most  of  the  sensors 
with  a  data  bus  interface  according  to 
Mil-Std-1553B  need  to  be  polled  within 
a  constant  time  period  to  prevent  data 
loss ., 


7  cyclic  with  delay, 

free-running,  no  entry 
initial  start  synchro¬ 
nized  by  initialisation 
routine 

main  purpose  to 
transport  data 


Synchronous  output  is  data  generated 
with  a  fixed  time  period  and  block 
size.  For  example  update/ refresh  data 
for  intelligent  sensors  needing  actual 
aircraft  position  for  calculating 
course  or  direction  is  synchronous 
output. 

Data  has  to  be  structured  in  order  to 
be  handled  properly  and  effectively.- 
One  measure  is  to  create  types,  but 
what  we  want  to  use  is  a  somewhat 
higher  level  of  abstraction.  This  is 
clarified  in  fig.-  8.  This  figure  shows 
a  section  of  the  input  data  flow  of  a 
distinct  sensor,  in  this  case  a  radar. 
Incoming  data  (the  messages)  is  held 
in  different  structures  according  to 
the  relevant  processing  stage.  The 
structures,  which  are  used  here,  are 
called  queue  and  pool  reap.  Similar  to 
this  we  have  to  provide  further  data 
structures  for  other  processing 
purposes.  The  structures  we  have  used 
within  MODOS  are 


-  fifo 

-  queue 

-  pool 

-  tree 

-  menu 

-  form 

-  window 


for  buffering  of  single  data 
for  buffering  of  messages 
for  data  base 

for  describing  a  hierarchy 
of  commands 

for  operator  comoiand  choice 
for  operator  generated  data 
entry 

for  data  or  image 
presentation 


The  first  4  structures  are  of  more 
general  character,  whilst  the  last  3 
are  special  for  the  workstation 
application. 


3.4  Tasks 


In  an  embedded  computer  system  where 
synchronous  and  asynchronous  data  is 
processed  the  software  design  has  to 
guarantee  that  all  events  are 
processed  in  time  independent  of  the 
basic  processor  workload.  It  is 
extremely  difficult  to  achieve  this 
within  a  purely  sequential  program 
structure,  if  there  is  a  number  of 
concurrent  processes.  One  may  easily 
derive  concurrency  between  for  example 
data  acquisition,  data  processing, 
data  presentation,  and  the  various 


cyclic  with  delay, 
free-running, 
with  entries 
initial  start  synchro¬ 
nized  by  initialisation 
routine 

main  purpose  to  perform 
high  level  system 
functions 

non-cyclic 

initial  start  synchro¬ 
nized  by  initialisation 
routine 

main  purpose  to  provide 
abstract  data  types 

The  first  category  contains  the  so 
called  actor  tasks.  These  tasks 
correspond  with  all  cyclic  aata 
transfer,  internally  as  well  as 
externally.  The  second  category, 
called  manager  tasks,  provides  high 
level  system  functions.  Most  of  these 
tasks  control  the  various  system  modes 
of  the  workstation  and  the 
environment.  The  third  category  is 
built  up  by  server  tasks,  which 
encapsulate  a  data  structure  and  the 
associated  functions  to  operate  on,  in 
other  words  an  abstract  data  type. 

While  the  design  as  a  task  is 
judicious  for  both  the  first  and 
second  category  namely  concurrency, 
the  decision  for  the  third  category 
has  to  be  explained.  An  abstract  data 
type  may  be  realized  of  course  by  a 
set  of  procedures  which  permit  the 
necessary  operations.  Now,  when 
different  tasks  access  the  same 
operation,  one  has  to  provide  some 
means  of  protection  against 
intermixing.  A  task  with  entries 
according  to  the  various  operations 
and  performing  these  operations  during 
rendezvous  is  a  very  suitable 
solution. 

Tasks  of  the  first  and  second  category 
are  called  active  tasks.  The  structure 
of  these  tasks  may  vary,  whereat  CPU 
time  consumption  may  be  a  driving 
design  consideration.  Fig.  10a  shows 
the  basic  active  task  type,  it  is  not 
waiting  for  any  external  event  or 
rendezvous.  Fig.  10b  shows  a  slight 


1. 


Manager  13 
Task 


Server  18 
Task 
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modification  to  allow  for  additional 
communication  with  other  tasks  or 
procedures  via  entry-calls.  Fig.  10c 
shows  a  further  modification  to  allow 
for  switch  on/off  on  request.  If 
switched  off  this  task  will  not 
consume  CPU  time  until  switched  on 
again.  The  state  of  the  task  can  be 
changed  by  different  events  (external 
interrupt,  rendezvous,  self- 
deactivation) .  A  last  example  with 
respect  to  task  design  is  given  in 
fig.  lOd  and  shows  the  combination  of 
a  server  task  and  an  active  task,  used 
for  the  handling  of  Mil-Std  1553B  data 
bus.  The  combination  provides  for  the 
possibility  to  use  different  task 
priorities.  Communication  between  the 
two  tasks  is  realized  by  a  fifo 
buffer. 

Designing  a  task  based  program 
structure  implies  also  to  take  care  of 
deadlocks.  Using  the  full  repertoire 
of  Ada  language  constructs  as  'select 
...  or",  "select  ...  else",  timed  or 
conditional  entry  calls,  "delay" 
statement,  and  watch-dog  timers  in 
conjunction  with  appropriate  transfer 
protocols  in  the  case  of  multi- 
rocessor  systems  may  help  to  avoid 
eadlocks.  For  our  MODOS  design  we  did 
some  Petri-net  modeling,  but  because 
of  deficiencies  of  the  tool  used,  we 
finally  relied  on  more  empirical 
methods. 

3.5  Interfaces 

A  C^  workstation  is  part  of  a  more 
comprehensive  system,  i.e.  there  are 
interfaces  to  the  environment,  which 
of  course  should  also  be  based  on 
standards  (table  3). 

Table  3:  Interface  Standards 


A.  Assessment 

We  would  like  to  pick  up  again  some  of 
the  before  addressed  aspects,  in  order 
to  assess  their  relevance  within  the 
MODOS  workstation  software  design. 
These  are 

-  Open  architecture/modularity 

-  Reusability 

-  Portability 

-  Testability/maintainability 

-  Real  time  processing  capability/ 
tasking 

In  addition  also  some  aspects  of 
object  oriented  design  (OOD)  will  be 
discussed. 

4.1  Open  architecture /modularity 

An  open  architecture  shall  allow  an 
ease  expansion  by  new  modules  to 
obtain  additional  features.  As  shown 
before  the  hardware  is  designed  for 
add-on  processors  thus  giving  the 
capability  of  a  separate  database 
processor,  an  extra  signal  processor 
or  something  like  that.  This  Implies 
the  distribution  of  software.  One  of 
the  expected  expansions  may  be  the 
employment  of  a  new  sensor.  In  this 
case  not  only  the  addition  of  new 
modules  is  necessary,  but  also  changes 
in  the  existing  software  have  to  be 
made.  As  long  as  data  structures  as 
menus  or  forms  are  concerned,  they  may 
easily  exchanged.  The  incorporation  of 
new  commands  into  the  control  task  is 
shown  in  fig.  9.  Modularity  gives  us 
still  more  flexibility:  exchangeable 
symbol  sets,  exchangeable  maps, 
variable  function  key  assignment  for 
example. 

4.2  Reusability 


Hardware:  STANAG  3838  (Mil-Std  1553B) 
RS232C/RS4?.?. 

SCSI 
RS  485 
ARINC  429 
others 

Software:  GKS  Level  2C 
SQL 

others 


Modularity  and  exchangeable  data 
structures  uiumoce  also  reuseability . 
For  new  applications  almost  all  of  the 
basic  software  represented  by  the 
inner  shells  of  the  formerly  shown 
software  layers  diagram  (fig.  6)  may 
be  reused.  All  abstract  data  types  are 
caiididates  for  reuse.  For  example 
within  MODOS  there  are  14  instances  of 
the  abstract  data  type  "queue". 


The  first  kind  of  interfaces  is  the 
connection  to  the  external  environment 
and  to  the  workstation’s  peripheral 
devices.  From  a  software  point  of  view 
the  only  consideration  is  whether  the 
necessary  drivers  have  to  be  written 
in  high  order  language  or  in  assembly 
language.  The  next  consideration 
refers  to  the  man-machine  interface. 
But  this  interface,  although  software- 
driven,  depends  on  system 
considerations.  The  third  kind  of 
interface  is  the  software  interface. 
Relevant  standards  we  have  mentioned 
in  the  beginning.  Beside  these  one  has 
to  pay  attention  to  the  required  open 
architecture.  The  software  structure 
should  be  designed  in  such  a  way,  that 
new  applications,  i.e.  new  software 
modules  may  be  built  in  easily. 


4.3  Portability 

Portability  is  widely  supported, 
because  only  a  small  amount  of  code, 
less  than  5  Z,  is  written  in  assembly 
language.  With  one  exception  no 
services  of  the  underlying  operating 
system  are  used  directly  by  the 
software.  Of  course  a  new  environment 
has  to  provide  a  GKS  interface. 


4.4  Testabilitv/Maintainabilitv 

Both  "-ilities"  are  strongly  supported 
by  modularisation  and  standardisation. 
Furthermore  a  clear  architecture  and 
identical  or  similar  instances  of 
software  components  assist  in 
testability  and  maintainability  resp. 
That  means,  that  both  will  be  achieved 
automatically  at  least  partly  if  the 
basic  design  considerations  are  obeyed 
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(besides  such  means  as  comments, 
programming  style  etc.).  Of  course 
testability  will  be  complicated  by 
concurrency. 

4.5  Real  time  processing  capability/ 
tasking 

The  extensive  use  of  tasks  may  cause 
roblems  with  real  time  processing 
ecause  of  accumulated  task  switching 
time  overhead.  We  have  experienced  no 
detrimental  effects,  which  is  of 
course  owning  to  the  ARTX  operating 
system.'  The  Do228  MPA  example 
mentioned  at  the  beginning  shows  a 
balanced  behaviour  between  processing 
capacity  and  data  transport  capacity. 
Furthermore  the  tasking  concept  is 
helpfull  when  distributing  software  in 
multiprocessor  systems. 


4.6  OOP 


5.  Conclusion 

Some  considerations  concerning 
software  design  of  a  command  and 
control  workstation  have  been 
presented  and  their  realisation 
explained  and  discussed.  The 
requirements  for  a  C  workstation  lie 
above  all  in  adaptability  to  different 
kinds  of  employment.  This  is  achieved 
by  the  current  software  design.  Far- 
reaching  requirements  as  hard  real 
time  processing  or  extreme  data 
throughput  may  be  satisfied  by  add-ons 
to  the  Sasic  design.  Because  of  the 
principles  of  modularisation  and 
standardisation  for  software  as  well 
as  for  hardware  stronger  requirements 
will  easily  be  met. 


Because  object  oriented  design  (OOD) 
is  now  the  favorite  software  design 
method,  we  are  caused  to  make  some 
remarks  on  it. 

For  the  software  design  of  MODOS  no 
special  OOD  method  and  tool  were 
applied.  Nevertheless  the  software 
architecture  was  built  up  in 
accordance  with  the  OOD  philosophy  of 
Grady  Booch.  Furthermore  the 
application  of  the  Ada  language 
supports  the  implementation  or  OOD  by 
providing  of  implementation  features 
as  follows 

o  structured  constructs 
0  typing 

0  interface  specifications 
0  information  hiding  and  data 
abstraction 

The  MODOS  software  architecture  is 
implemented  by  an  Ada  package 
hierarchy  which  is  defined  by  the  use 
relationship.  The  objects  of ' the  MODOS 
software  are  represented  by  Ada 
packa5;es  or  compositions  of  Ada 
packages . 

The  top  level  objects  like  (see  also 
fig-  7) 

o  Environment  I/F  Management 
o  Sensor  Management 
0  Data  Storage 
0  Data  Fusion/Tactics 
0  MMl 

are  created  in  accordance  with  the 
real-world  objects  of  the  MODOS 
system.  Those  objects  group  only  lower 
level  objects  to  one  object  which 
represents  a  real-world  entity. 

From  the  software  engineering  point  of 
view  more  efficient  objects  are  the 
low  level  objects  of  the  MODOS 
software  architecture.  These  objects 
are  implemented  as  an  Abstract  Data 
Type.  Most  of  them  are  multiple  used. 


a)  Basic  Configuration  b)  Multiple  Sensor  -  Single  Workstation  Contig 


c)  Multiple  Sensor/Effector  -  Multiple  Workstation  Configuration 


Fig.  1 :  System  Configurations 
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Fig.  2;  C^Workstations  Applications  in  ASW  Missions 


Fig.  3:  C^Workstations  in  Oil  Spill  Detection  Missions 
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Fig.  4:  Workstation  Blockdiagram 


Fig.  5:  Modular  Operator  Station  MODOS 
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a)  Context  Diagram 


b)  First  level  of  decomposition 


c)  Second  Level  (tirst  level  of  decomposition  of  MMI) 

Fig.  7 :  SW  Architecture  -  Decomposition 
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Fig.  8;  Data  Flow 


Tracks 

p 


Fig.  9:  Principle  of  mode/function  control 
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task  body  actor_task  is 
—  local  declarations 
begin 


—  Before  the  task  can  run  it  must  be 

—  explicitly  started. 

accept  start  (...)  do 

—  initialize  variables  and  return 

—  initialisation  status. 

end  start; 

—  Now  the  task  is  active  and  can  run  freely 

—  except  when  the  delay-statement 

—  is  executed. 

loop 

statements ; 

—  allow  other  tasks  to  run 

delay  specific_time; 
statements ; 
end  loop; 

end  norma l_task_type_l 


Fig.  10 j  Active  Tasks  Examples 

aj  free-running  with  delay 


task  body  manager_task  is 
—  local  declarations 
begin 


—  Before  the  task  can  run  it  must  be 

—  explicitly  started. 

accept  start  (...)  do 

—  initialize  variables  and  return 

—  initialisation  status. 

end  start; 

—  Now  the  task  is  active  and  can  run  freely 

—  except  when  the  delay-statement 

—  is  executed. 

loop 

select 

accept  entry_a  (...)  do 

—  perform  rendezvous 
end  entry_a; 

(  statements;  ] 
or 

accept  entry_b  (...)  do 

—  perform  rendezvous 
end  entry_b; 

(  statements ;  ] 
or 

[  when  boolean_expression  =>  ] 
accept  entry_c  (...)  do 
--  perform  rendezvous 
end  entry_c; 

[  statements;  ] 


else 

[  statements;  ] 

—  allow  other  tasks  to  run 

delay  specif ic_time; 
end  select; 
end  loop; 

end  norma l_ta8k_type_2 


Fig.  10  (cont.);  Active  Tasks  Examples 

bi  free-running  with  delay  and  entries 
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task  body  switching_task  is 
--  local  declarations 
begin 


—  Before  the  task  can  run  it  must  be 

—  explicitly  started. 

accept  start  (...)  do 

—  initialize  variables  and  return 

—  initialisation  status. 

end  start; 

inactive: 

loop 

accept  activate_entry  (...)  do 
—  perform  rendezvous 
end  activate_entry; 
active: 
loop 

select 

accept  deactivate_entry  (...)  do 

—  perfom  rendezvous 
end  deactivate_entry; 

[  statements ;  ] 
or 

accept  entry_b  (...)  do 

—  perform- rendezvous 
end  entry_b; 

[  statements ;  ] 
or 

[  when  boolean_expre88ion  *>  ) 
accept  entry_c  (...)  do 

—  perform  rendezvous 
end  entry_c; 

[  statements;  ] 


else 

[  statements;  ] 

—  possibility  for  the  task  to 

—  deactivate  itself 

exit  active  when  . . . . ; 

—  allow  other  tasks  to  run 

delay  specif ic_time; 
end  select; 
end  loop  active; 
end  loop  inactive; 
end  switching  task; 


Fig.  10  (cont.):  Active  Tasks  Examples 

c:  same  as  10b  plus  switching  capability 


package  body  milbus  is 


task  body  manager  is 

—  this  task  has  the  default  task  priority 
task  driver  is 

pragma  priority  ( system. priority' last ) ; 

—  highest  priority 

entry  start  (frame_time  :  in  duration); 
entry  milbus_interrupt; 

for  milbus_interrupt  use  at  . . . ; 
end  driver;  ~ 

task  body  driver  is 
fr_time  ;  duration; 
begin 

accept  start  (frame_tiwe  ;  in  duration)  do 
—  perform  rendezvous 
fr_time  t=  frame_time; 

[  statements;  J 
end  start; 
loop 

[  statements;  ] 
accept  milbus_interrupt; 

[  statements ;  ) 
delay  fr_time; 
end  loop; 
end  driver; 

begin  —  of  milbus .manager 
accept  phase_0  (...)  do 
(  statements ;  ] 
end  pha8e_0; 

—  begin  of  phase  0 

phaseO : 
loop 

select 

accept  enter_message  (...)  do 
(  statements;  ] 
and  enter_message; 
or 

accept  phase_l; 
exit  phaseO; 
end  select; 
end  loop  phaseO; 

—  begin  of  phase  1 

phasel: 

loop 

select 

accept  new_frarae  (...)  do 
[  statements ;  ) 
end  new_frame; 


(to  be  continued) 
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or 

accept  enter_message_descriptor  (...)  do 
[  statements ;  ] 
end  enter_message_descriptor; 
or 

accept  phase_2 

(freune_tiine  :  in  duration  )  do 
[  statements;  ] 
end  phase_2; 
exit  phasel; 
end  select; 
end  loop  phasel; 

—  begin  of  phase  2 
driver. start  (frame_time) ; 

—  now  the  driver  task  is  activated 

phase2 : 
loop 

select 

accept  availablejmessages 
(count  :  out  natural)  do 
[  statements;  } 
end  available_messages; 
or 

accept  get_message  (msg  :  out  message)  do 
[  statements;  ] 
end  get_mes8age; 
or 

accept  send_extra_mes8age 
(msg  t  in  message)  do 
[  statements;  ] 
end  send_extra_message; 

O'- 

accept  change_messr.ge  (...)  do 
[  statements;  ] 
end  ch8nge_me88age; 
end  select; 
end  loop  phase2; 
end  manager; 
end  milbus; 


Fig.  10  (concl.)j  Active  Tasks  Examples 

d:  Combination  of  active  task  and  passive  task 
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Abstract 

We  expose  an  exi'Orience  of  using  formal  algebraic 
specifications,  conducted  in  collaboration  with  an 
aeronautic  industry.  The  objective  is  to  provide  a 
reusable  specification  of  processing  telemetry  results. 
This  family  of  spatial  applications  is  described  by 
means  of  generic  formal  specifications,  and  each 
telemetry  could  be  built  from  them.  Reuse 
possibilities  are  supported  by  our  framework  In  this 
paper,  we  give  a  general  survey  of  this  experience, 
including  its  “story”,  the  method  followed  for 
establishing  the  generic  specifications  which  are  the 
system  core,  and  reuse  aspects  provided. 

Keywords:  formal  specification,  telemetry 
decommutation,  design  and  software  reuse,  fast 
prototyping,  requirements  elaboration. 

Introduction 

It  is  obvious  to  say  that  software  becomes  more  and 
more  complex  and  of  course  as  a  direct  consequence 
more  and  more  expensive  to  develop.  Too  much 
work,  too  much  time  are  necessary  to  get  an 
operational  version  of  a  software  product.  Among  the 
reasons  responsible  of  such  difficulties  in  the  software 
production,  at  least  two  are  of  first  importance. 

First  of  all,  the  development  process  activity  is 
slowed  down  each  time  the  description  of  the  system 
to  be  produced  is  not  precise  enough  and  requires  to 
make  decisions  all  along  development.  Unfortunately, 
this  appears  any  time  the  requirements  document  is 
expressed  in  a  natural  language.  It  is  impossible  to 
guarantee  that  such  a  document  describes,  in  an 
unambiguous  way,  what  the  system  has  to  do.  flow 
to  know  whether  or  not  the  document  is  complete 
(has  everything  been  said?)  and  consistent  (is  there 
110  contradiction)? 

•This  work  was  supported  by  a  contract  between  ONES 
and  GRECO-PRC  PROGRAMMATION.  This  action  of  tech- 
noloi^  transfer  has  been  managed  by  two  teams*  in  Grenoble 
(IMAG/LIFIA)  and  Toulouse  (ONERA-CERT/DERI). 


The  second  reason  is  the  origin  of  the  reuse  notion. 
Many  studies  have  shown  that  a  lot  of  functionalities 
are  repeated  from  one  application  to  another.  What 
about  reusing  at  least  final  codes’  It  is  clear  that  the 
ability  to  reuse  software  is  a  mam  key  to  the  software 
success;  the  gains  we  can  expect  are  of  course 
important  from  the  viewpoint  of  economy  in  terms  of 
work  and  time  But  another  perhaps  more  important 
gain  is  obtained  if  the  reused  and/or  adapted  parts 
have  been  proved  correct  once  and  for  ever 

A  means  to  decrease  the  underlying  difficulties  is  to 
start  the  development  process-before  beginning  the 
coding  phase — by  a  first  description  of  the 
application  in  a  very  high  level  formalism.  The  goal 
of  this  description  we  cal!  specification  is  to  express 
the  application  in  a  formal  language.  By  formal  is 
meant  a  language  for  which  the  mathematical 
foundations  arc  precisely  establislied  both  from  the 
viewpoint  of  its  syntax  and  semantics.  Because  the 
use  of  a  formal  language  requires  a  precise 
description  of  all  the  wished  functionalities,  any 
problem  expressed  with  such  a  formalism  will  have 
one  and  onip  one  interpretation,  the  same  for  all 
kind  of  users  (men  and  computers). 

Among  the  precise  specification  formalisms,  one 
seems  quite  interesting,  it  is  called  algebraic 
specification  because  it  is  based  on  specifying  types 
as  value  sets  and  functions  in  an  equational  way  to 
express  function  behaviour.  Moreover,  it  is  possible 
to  parameterize  an  algebraic  specification  by  another 
which  represents  hypotheses  Such  parameterized 
specifications  are  also  called  generic  specifications 
At  the  last,  let  us  remark  that  under  certain 
conventions,  some  algebraic  specifications  can  be  run 
and  play  the  role  of  a  prototype.  (Concerning  this 
specification  formalism,  its  theoretical  notions  can  be 
found  in  [4].) 

In  ail  the  cases,  the  specification  activity  obliges  to 
ask  ourselves  the  tight  questions  and  to  give  the 
right  answers  by  fixing — in  a  not  necessarily 
definitive  way — the  choices  related  to  the 
functionalities  to  provide.  This  step  is  compatible 
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with  the  reuse  problem.  Indeed  when  we  consider 
related  applications,  the  use  of  abstraciton  for 
synonymous  functionalities  allows  a  better 
obviousness  of  common  parts. 

In  this  paper,  we  present  an  experience  of  using 
formal  specifications  within  the  context  of  an 
industrial  and  spatial  application:  telemetry 
systems.  As  it  will  be  mentioned  later,  the  reuse 
objective  is  always  present.  A  complete  description 
of  this  experience  is  available  in  [9].  [10]  points  out 
the  didactic  results  of  this  operation  a.id  also  gives 
the  ONES  (Centre  National  d’Etudes  Spatiales: 
National  French  Space  Agency)  viewpoint.  In  this 
paper,  we  emphasize  more  the  followed  process  and 
the  main  results  considered  from  a  methodological 
viewpoint.  In  Section  1,  we  quickly  recall  the  study 
evolution.  Section  2  points  out  out  principles  for 
writing  this  specification.  Section  3  summarizes  the 
lessons  and  perspectives  this  work  opens. 

1  “Story”  of  the  study — The 
chosen  approach 

The  telecommunication  division  of  the  CNES  is  in 
charge  (among  others)  of  writing  the  requiienient 
documents  relative  to  the  telemetry  systems.  Then  it 
asks  software  houses  to  develop  the  corresponding 
software  system  Up  to  now,  all  the  telemetry 
systems  were  developed  independently  each  others 
even  if  obviously  some  phases  of  the  telemetry 
processing  are  similar  from  one  telemetry  to  another 
Here  is  the  starting  point  of  our  study;  to  show  that 
some  (supposed)  reusable  parts  can  be  clTcctivcly 
reused  for  any  kind  of  telemetry  systems  by  means  of 
reusable  software  components. 

Our  basic  idea  was  to  develop  an  only  and  formal 
requirement  document  from  the  informal  ones  which 
described  a  few  existing  telemetry  systems.  Instead 
of  this,  another  approach  should  have  been  to 
develop  more  or  less  directly  reusable  .software 
components.  This  second  approach  has  not  been 
achieved  for  assessment  reasons  and  also  to 
guarantee  that  the  reusable  software  can  be  keep  free 
from  any  implementation  language. 

The  study  was  started  with  five  diiTerent  telemetry 
systems.  VVe  tried  to  exhibit  all  the  common 
functionalities  between  them.  This  top  down 
approach  was  abandoned  because. 

•  the  difficulty  to  understand  the  informal 
documents,  indeed,  there  are  so  many 
incompletenesses,  too  much  implicit  that  only  a 
specialist  of  this  domain  was  able  to  understand 
such  docum  ats; 

•  each  document  was  specific  to  a  given  telemetry 
system:  in  other  words,  each  document  reflects 
the  description  of  one  telemetry  system  outside 
any  global  consideration — for  instance,  the  used 


terminology  was  often  different  from  one  sj  ‘en. 
to  another. 

It  might  have  been  possible  to  isolate  in  a  very  hand 
fashion  the  common  functionalities  but  without  any 
warranty  of  keeping  consistent  the  overall 
understanding  of  what  a  telemetry  system  was. 
Another  point  to  be  rem  -mber  is  the  fact  that  the 
cljcuments  we  hud  in  hands  were  about  yet  ezislmg 
telemetry  systems  and  that  we  were  ir.'  ■■  '-.icd  in 
developing  a  general  and  formal  telemetry 
description  for  future  systems.  What  should  have 
been  the  adequacy  of  a  new  system  in  such  a 
context?  What  credibility  should  have  been  given? 
This  problem  has  been  mentioned  many  times;  what 
has  not  been  developed  with  a  reusability  aspect  is 
difficult,  even  impossible  to  reuse!  Here  was  the 
main  reason  we  started  in  another  direction. 

First  of  all  we  asked  the  telemetry  specialists  to 
describe  in  an  informal  but  rigorous  manner  what  a 
telemetry  system  is  from  an  abstract  viewpoint. 

Then  after  several  in.spections,  this  document  [5]  was 
formalized  in  terms  of  generic  specifications  we  will 
call  generic  telemetry  in  the  rest  of  the  paper.  Of 
course,  all  the  problems  were  not  solved  in  [5). 
Nevertheless,  its  main  advantage  was  that  it  was 
independent  on  any  existing  or  future  telemetry 
system  and  it  was  readable  enough  for  non  specialists 
of  the  field  as  we  were. 

The  generic  telemetry  gathers  the  description  of  all 
the  entities  involved  in  any  telemetry  system.  It 
looks  like  a  general  framework  from  which  any 
telemetry  specification  could  be  built.  It  is  evident 
that  the  informal  general  document  was  not  aole  to 
take  into  account  all  the  cases.  Thus  the  generic 
telemetry  is  open  (e.g.  new  elements  can  be  easily 
added)  and  very  abstract  in  order  not  to  be  too 
restrictive  or  too  dependent  on  any  particular  case. 

In  practice  to  the  contrary  of  the  first  approach,  this 
second  one  is  definitively  bottom  up.  Indeed,  it  is 
more  simple  to  ennch  a  generic  specification  with 
new  elements  (not  yet  considered  as  generic  enough) 
than  to  suppress  peculiar  characteristics  that  had 
unfortunately  been  considered  general. 

Having  written  the  generic  telemetry  during  the  first 
part  of  this  operation,  it  was  interesting  to  test  it  on 
a  real  case.  We  have  done  this  work  with  a  telemetry 
of  the  scientific  project  INTERBALL.  As  mentioned 
above,  it  was  necessary  to  enrich  the  generic 
telemetry.  The  example  has  been  fully  developed  for 
Its  main  difficult  parts;  generation  and  storage  of 
embedded  iiiforination  according  to  an  INTERBALL 
format,  and  dccomiiiutalion  of  the  received  data  at 
ground. 

A  few  remarks: 

•  due  to  the  chosen  specification  language  we  have 
been  able  to  run  parts  of  this  instantiated 
specification.  This  point  is  very  comfortable. 
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Indeed,  it  is  not  necessary  to  wait  for  the  end  of 
the  project  to  get  some  results  allowing  the 
specifier  to  prove  the  project  under 
consideration  is  really  effective; 

•  the  internal  and  external  presentations  of 
information  ate  similar;  this  improves  the 
readability  of  the  formal  specification  and  allows 
updating  it  easily  in  case  of  any  modification  to 
the  external  view; 

•  the  enrichment  of  an  instance  of  the  generic 
telemetry  must  be  done  with  in  the  mind  the 
reuse  goal  of  the  added  information  (we  will  go 
thoroughly  this  point  in  §3.1). 

2  Specifying  telemetries:  tool 
and  method 

Now  we  are  going  to  tackle  more  technical  features. 
First,  we  describe  any  telemetry  process  succinctly. 
Then  we  explain  how  we  have  specified  is  as  the 
generic  telemetry  using  generic  specifications.  We 
illustrate  our  method  by  an  excerpt  from  these 
specifications,  from  which  we  take  some  examples 
At  the  last,  we  briefly  show  an  example  of  its  use 

2.1  General  description  of  telemetries 

The  aim  of  any  telemetry  process  is  to  make  up  the 
measurement  results  effected  by  a  scientific  satellite 
The  data  of  each  experiment  must  be  provided  in 
chronological  order  to  the  organization  which 
manages  it. 

Any  telemetry  system  is  divided  in  two  subsystems: 
an  on-board  system  and  a  ground  one,  as  shown  in 
Figure  1.  The  on-board  system  includes  a 
transmitter  which  sends  telemetry  results  to  ground 
stations.  If  the  satellite  is  geostationary, 
transmissions  are  direct  and  purely  sequential.  In  the 
general  case,  the  satellite  moves.  There  are  several 
stations,  and  the  satellite  faces  one  of  them  only 
during  a  little  while.  While  the  satellite  does  not  face 
any  station,  it  records  telemetry  results  to  be 
transmitted  in  a  storage  zone.  When  it  is  within 
sight  of  one,  it  transmits  both  direct  and  recorded 
telemetries.  That  is  why  it  is  necessary  to  order 
results  according  to  their  dates  afterwards. 

information  provided  inside  satellites  is  constituted 
by  bit  strings,  according  to  a  specific  format  for  each 
embedded  experiment  Before  transmission  to 
ground,  the  satellite  mixes  these  bit  strings  into  byte 
matrices  according  to  a  distribution  called 
telemetry  format.  Such  a  format  depends  on  the 
considered  satellite.  On  the  ground,  separating  data 
according  to  their  origin  among  the  received  byte 
matrices,  in  order  to  reconstruct  original  bit  strings, 
is  called  telemetry  decommiitation. 


2.2  Our  approach 

2.2.1  FVame 

As  we  have  exposed  in  Section  1,  our  approach 
proceeds  by  using  parameterized  specifications.  For 
any  telemetry,  our  framework  for  specifying  is 
divided  in  two  parts: 

•  the  generic  telemetry  specification:  it 
includes,  on  the  one  hand,  the  operations  which 
are  present  in  all  the  telemetries  (e.g.  a  sort 
according  to  a  time  base),  on  the  other  hand, 
the  description  of  all  the  entities  which 
participate  in  any  telemetry  and  functionalities 
which  equip  these  entities. 

•  the  instantiation,  i.e.  the  bindings  of  formal 
parameters  to  actual  values.  These  actual  values 
are  supposed  to  be  specified:  they  represent  the 
specific  conventions  for  the  considered  telemetry. 

In  order  that  modularity  of  out  specification  respects 
the  telemetry  organization  given  in  Figure  1,  we  have 
written  one  module  for  one  entity.  These  modules  are 
parameter  specifications:  because  of  their  generalne.ss 
character,  they  do  not  represent  the  entities  of  a 
particular  telemetry,  but  they  must  be  templates, 
such  that  the  specification  of  any  telemetry  entities 
can  be  obtained  by  replacing  the  module  parameters 
by  the  conventions  of  this  telemetry. 

2.2.2  A  limitation 

For  any  telemetry,  the  number  nb-exp  of  embedded 
experiments  and  nb-ts  of  technologic  sets 
(cf.  Figure  1)  depends  on  the  considered  telemetry. 
Let  us  recall  that  any  experiment  and  technologic  set 
are  represented  by  a  parameter  specification  in  our 
framework,  according  to  the  principles  we  have 
stated  in  the  previous  subsection.  If  we  consider  any 
telemetry  process  in  a  global  way,  we  obtain 
parameter  specifications  which  ate  parameterized 
themselves — they  are  parameterized  respectively  by 
the  natural  numbers  nb-exp  and  nb-ts. 

As  far  as  we  know,  any  algebraic  specification 
language  provides  neither  theoretical  nor  practical 
tools  to  describe  such  a  specification.  Some  ways  to 
cope  this  limitation  exist.  Since  we  are  interested  in 
providing  a  very  readable  specification  especially,  we 
have  chosen  the  solution  we  think  it  is  the  simplest 
in  a  didactic  way;  we  consider  one  experiment,  and 
one  technologic  set.  Generalizing  these  two 
specifications  to  describing  nb-exp  xperiments  and 
nb-ts  would  make  them  more  complex,  hut  does  not 
constitute  a  real  problem.  In  order  to  be  exhaustive, 
it  seems  important  to  us  to  report  this  limitation  but 
we  claim  it  is  the  only  actual  limitation  we  come  up 
against  while  specifying  these  spatial  applications. 
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2.2.3  Method 

Now  we  are  going  to  explain  the  principles  which 
have  guided  us  in  writing  the  modules  of  the  generic 
telemetry  specification  Figure  2  gives  one  of 
representative  excerpts.  Readers  interested  in  the 
complete  text  can  find  it  in  [8]  Some  technical 
notions  about  our  notations  are  given  in  Annex. 

Because  of  their  algebraic  character,  the 
specifications  we  propose  comprise  both  types  and 
functionahUcs.  In  these  parameter  specifications,  we 
understand  types  as  possible  value  sets:  for  example, 
the  modes  of  a  telemetry,  which  give  access  to  the 
different  telemetry  formats,  form  a  specific  type  for 
this  telemetry  (In  Figure  2,  we  note  tm-mode  this 
type  which  depends  on  the  considered  telemetry ) 

Functionalities  are  actions  on  types;  they  are 
characterized  by  their  inputs  and  outputs,  and  they 
are  represented  by  means  of  operators  For  example, 
reception  of  data  from  the  experiment  is  made  by 
means  of  the  operator 

receive-exp 

who.se  domain  is- 
tm-mode 

X 

Seq[Ftxed-Array  Ftype-and-Nat[Bit  /  eip-dinii]] 

X 

S’ci}[Af nlrii  Flype-and-2-Nal{Byte 

/ 

nh-rows,  n6-Ai/t«s)] 

and  codomam  is. 

Seq[Matrix  Flype-and-2-Nat[Byle 

/ 

nb-rows,  nb-byies]] 

(For  more  details  about  these  type  expressions  and 
meaning  of  our  identifiers,  see  the  commentaries  in 
Figure  2  and  Annex.) 

In  a  concrete  way,  the  argument  of  sort  tm-mode  is 
the  current  working  mode  when  the  data  are 
received  These  data  are  organized  in  an  array 
sequence  using  the  experiment  format,  and  this 
operation  takes  also  a  matrix  sequence  using  the 
telemetry  format — obtained  from  tm-mode — in  which 
information  is  put  in  the  appropriate  places  In 
another  way,  the  “new”  matrices  are  obtained  from 
the  “old"  ones  by  addition  of  experiment  data  (Let 
us  recall  that  there  cannot  be  side  effect  since  we 
consider  Junctions  in  a  purely  mathematical  sense  ) 

According  to  [5],  a  telemetry  format  is  a  byie  matrix 
whose  dimensions  are  specific  to  the  considered 
telemetry.  In  such  a  way,  the  distribution  inside  this 
matrix  depends  on  the  telemetry,  too.  And  no 
additional  information  is  provided.  Principles  for 
these  distributions  may  be  very  different  from  one 


telemetry  to  another.  Let  us  cite  two  examples 
here — cf.  [8]  for  more  details. 

The  formats  of  the  UARS-VVINDII  telemetry  is 
divided  in  vertical  sections  corresponding  to  the 
different  kinds  of  data  which  they  contain  As 
another  way,  the  INTERBALL  telemetry  formats  are 
described  byte  by  byte 

Since  no  unified  approach  for  describing  any 
telemetry  format  exists,  our  solution  is  to  consider  a 
telemetry  format  as  an  object,  according  to  the 
object-oriented  approach.  We  do  not  know  its 
representation  and  we  have  access  to  it  only  by 
methods.  In  our  case,  the  methods  are: 

•  storing  data  into  telemetry  formats — it  is  done 
by  means  of: 

*  the  operator  receive-cxp  for  the  telemetry 
experiment. 

*  the  operator  receive-techno  for  the 
technologic  set 

•  dccommutation  of  formats  in  order  to  provide 
the  different  kinds  of  data  these  two  op-'rators 
(for  the  experiment  of  the  telemetry  and  its 
technologic  set)  are  included  in  the  specification 
of  ground  operations. 

•  some  additional  information  bound  to  the 
format — e  g.  the  synchronization  words'  they  are 
used  to  control  the  reliability  of  the  data  flows 

This  point  ends  the  presentation  of  the  principles  we 
have  followed  for  exhibiting  types  and  operators  from 
the  informal  document  [5].  We  cannot  go  thoroughly 
the  specification  of  storing  and  decommutation  since 
It  narrowly  depends  on  the  considered  telemetry 
format.  Thus  oiir  generic  telemetry  is  a  framework 
for  formally  specifying  how  to  built  any  telemetry 
specification  from  it  Applications  to  reuse  objective 
will  be  seen  in  §3  1,  after  a  short  survey  about  the 
instantiation  we  have  studied  during  the  second  part 
of  this  work 

2.3  Instantiating  the  generic 
telemetry 

As  mentioned  already,  the  distribution  of  the 
INTEIIBALL  telemetry  formats  is  given  byte  by 
byte,  according  to  the  different  kinds  of  data.  An 
important  point  fo-  our  specification  is  that  our  way 
for  describing  the  format  conventions  is  very  near  to 
what  IS  depicted  in  the  project  documents.  For 
storing  and  decommutation,  the  different  bytes  are 
used  as  a  gnd  in  which  holes  indicate  places  for 
deposing  or  extracting  information  [9].  We  do  not 
detail  this  feature  here,  and  are  going  to  be  rather 
interested  in  replacing  some  elements  of  the  generic 
telemetry  For  example,  some  dimensions  are 
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—  This  is  a  commentary.  See  Annex  for  more  details  about  some  technical  notions. 


prop  Saielliie-Features[tm-mode, 


bit-rate 


Working  mode:  it  provides  access  to  each 
telemetry  format  used. 

Type  of  all  different  bit  rates  for 
transmissions. 


exp-dimi,receive-exp, 
techno- dimi,receive-techno,  — 


nb-Tows,  nb-bytes, 
diini ,  dim2,  corr. 


mode-rate, 

obiain-time, 

Ig-synchro, 

synchro] 


How  to  receive  the  results. . . 

. .  .of  one  experiment  (cf.  §2.2.2)  whose  format 
dimension  is  exp-dimi , 

...  of  one  technologic  set  whose  format 
dimension  is  techno-dim\. 

In  these  two  cases,  let  us  recall  that  the  used 
telemetry  format  depends  on  the  working 
mode  tm-mode. 

Dimensions  for  the  matrices  of  telemetry 
formats. 

Data  enrichment  by  an  error-correcting  code. 
dimi  and  dimj  are  respectively  the 
dimensions  of  the  original  array  and  the 
enriched  one.  corr  is  the  coding  operator. 
Bindings:  working  mode  i-*  corresponding  bit 
rate. 

How  to  get  dates. 

Common  length  of  synchronization  words. 

The  synchronization  words  themselves. 


—  Domains  and  codomains  of  the  operators: 
exp-dimi ,  techno-dimi ,  nb-rows,  nb-bytes,  dimj ,  dim} ,  lg-r,ynchro  •  - 
Nat 

receive-exp  tm-mode  x  SeqlFixed-Array.Ftype-and-Nat[Bit  /  e*p-d>mi])  x 

Seq[Matrtx.Ftype-and-2-NatlByte  /  ni-rouiSint-fcj/fes]] 
Seq[Matrix  Ftype-and-2-Nat\Byte  /  nb-rows,  nb-bytes]] 
receive-techno  ■  tm-mode  x  Seq[Fixed-Array.Ftype-and-Nat[Bii  /  tec/mo-dimi]]  x 
Seq[M atrix.Ftype-and-2-Nat[Byte  /  nb-rows,  uli-61/ies))) 
Seq[Matriz.Ftype-and-2-Nal[Byle  /  nb-rows,  nb-bytes]] 
corr  Fixed- Array. Ftype-and-Nat[Bit  /  dimi] 

Fixed- Array. Ftype-and-Nat[Bit  /  dim}] 
mode-rate  :  tm-mode 
bit-rate 

obtain-time  Nat 

Time 


receive-techno 


mode-rate 


obtain-time 


synchro 


Seq[Fixed-Array.Ftype-and-Nat[Byte  /  Ig-synchro]] 


—  No  specific  axiom  in  these  module  (cf.  §2.2.3). 

includes  —  Using  the  specification  of  any  error-correcting  code: 

Using- Error-Codes]  /  dimj,dim2,corr), 

—  General  binding  of  modes  to  rates: 
Bit-Rates-and-Modes[tm-mode,bit-rate  /  mode-rafe) 


endprop 


Figure  2:  Data  reception  inside  any  scientific  satellite. 
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instantiated  as  follows: 


nb-rows  (-►  32 
nb-bytes  16 
ig-synchro  >-*  7 


and  the  synchronization  words  are — they  are  given 
using  hexadecimal  codes — : 


[(”F5”,  ”F6”,  ”C0”, 
rC5”,  ”C6”,  "DO", 
(”D5”,”D6”,”E0”, 
(”E5”,  ”E6”,  ”F0”, 


”C1”,  "C2”,  ”C3”,  "C4”), 
”Dr,"D2",”D3”,”D4”}, 
”E1”,”E2”,”E3”,"E4”}, 
”F1”,  ”F2”,  ”F3”,  "F4”)l 


3  Specifying  an  application 
family 

3.1  The  ways  to  reuse 

Hy  using  our  framework  for  developing  telemetries, 
an  environment  for  this  comprises  the  generic 
telemetry  and  instantiations  for  obtaining  some 
telemetries.  Each  instantiation  leads  to  a 
specification  which  is  vnpkmenied  using  a 
programming  language.  This  global  situation  is 
depicted  in  Figure  3.  Two  possibilities  lor  reu.sing 
exist. 

Rcuso  of  the  generic  part  If  the  used 

programming  language  supports  gcnericity  (like 
Ada),  the  operators  of  which  we  give  the 
behaviour  (e.g.  the  chronological  sort)  can  be 
implemented  once  and  reused  for  each  new 
telemetry. 

Ilcn.sc  of  iinploiuentntions  If  we  find  out— when 
we  integrating  it— that  the  instantiation  of  a 
new  telemetry  is  the  same  as  a  previous  one, 
then  reuse  of  implementation  of  this  previous 
telemetry  is  allowed. 

'I'liis  second  case  can  be  extended  when  only  tniilus 
are  identical,  but  the  implementation  process  must 
have  respected  the  specification  modularity  m  order 
that  reuse  is  possible. 

In  order  to  guarantee  reuse,  it  is  crucial  that  the 
consistence  are  maintained.  As  a  consequence, 
modifying  generic  telemetry—  for  correcting  an  error, 
adding  a  forgotten  functionality,  or  reporting  a 
standard  change— should  be  followed  by  an 
up-  to-date  about  all  the  instantiations.  Otherwise,  it 
is  desirable  to  consider  the  “new”  generic  telemetry 
specification  as  a  core  of  a  new  tool. 


3.2  Lessons 

If  we  try  to  summarize  the  presented  application, 
several  lessons  have  been  learned.  .According  to  what 
has  been  done,  we  can  affirm  that  using  a  very  high 
formalism  for  expressing  of  real  problem  is 
mandatory  for  many  reasons' 


•  the  establishment  of  a  real  specification  in  which 
every  thing  is  explained  and  where  no  ambiguity 
remains; 

•  an  efficient  means  for  developing  a  software 
family  where  the  main  keyword  is  reuse; 

•  a  first  prototype  of  the  system  has  been 
developed; 

•  writing  a  formal  document  which  represents 
what  the  order  wants  in  a  very  clear  manner. 
This  document  may  be  considered  as  well  as  a 
reference  document  for  the  following  steps  of  the 
Software  Life  Cycle.  As  main  consequence,  this 
document  can  also  be  reused  along  the 
development  piocess  for  verification  and 
validation  purposes 

Moreover  we  have  shown  that  using  a  peculiar 
formalism  such  as  an  algebraic  specification  language 
IS  not  too  difficult  if  the  semantic  distance  between 
the  application  and  the  chosen  formalism  is  not  too 

high 

We  have  been  very  surprised  from  our  viewpoint  to 
sec  that  telemetry  specialists  have  accepted  to  learn 
the  (very  strange)  formal  language  and  are  noa'  able 
to  read  our  telcinctr)  specifications. 


Conclusion 

Now  writing  a  formal  specification  is  becoming  a 
fca.siblc  task  at  the  industrial  level.  Some  large 
applications  have  been  described  with  algebraic 
specification.  As  an  example,  a  specification  of  the 
File  Management  System  of  UNIX  is  described  in  (3). 
The  piirpo.se  of  that  specification  was  to  study  the 
ambiguities,  contradictions,  incompletenesses, 
inconsistencies  of  part  of  an  operating  system  such  ns 
UNIX  We  will  .say  that  kind  of  formal  specifications 
have  been  writt.-n  in  order  to  evaluate  all  the  power 
of  formal  spedrications  on  a  concrete  example. 

In  our  context,  the  CNES  which  is  more  a  client 
than  a  developer  had  put  the  main  emphasize  about 
maintenance  and  reuse  of  software  systems.  The 
formal  general  specification— describing  an 
application  family — it  is  not  too  dilficult  to  maintain 
and  in  case  of  any  modification  at  the  highest  level. 
It  is  easy  to  measure  the  consequence  on  the  final 
codes  w.ien  these  codes  have  been  implemented  by 
following  the  specification  modularity.  In  case  of 
development  of  a  new  but  similar  system  an 
instantiation  is  straightforward. 

Nevertheless  a  few  drawbacks  do  exist. 

The  first  one  is  about  the  kind  of  languages  we  can 
use.  These  languages  are  generally  based  on 
mathematical  notions  They  are  not  readable  enough 
as  should  be  dedicated  interfaces. 
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Figure  3:  Integrating  a  new  telemetry  with  reuse. 


'Die  second  drawback  is  related  to  the  lack  of 
industrial  environment  supporting  formal  languagc.s 
and  formal  methods.  Indeed,  even  if  formal  methods 
such  as  VDM  [11]  do  exist  and  are  in  practice,  they 
suffer  from  a  lack  of  support  tools. 

The  third  one  is  about  the  expressive  power  of 
formal  languages.  As  it  can  be  read  in  this  paper, 
functionalities  are  easily  described.  What  about  the 
operational  properties  of  a  system?  By  operational 
properties  is  meant  real  time  constraint  such  as  lime 
and  space  but  also  other  properties  such  as 
friendliness  of  the  interfaces. 

All  the  drawbacks  will  be  overridden  very  soon. 

The  first  point  is  currently  being  solved  by 
education.  The  academia  has  started  teaching  formal 
languages  and  formal  methods  as  well  a  few  years 
ago.  The  new  generation  of  computer  scientist  will 
be  able  to  tackle  the  problem  of  specifying  formally. 

'File  second  point  is  fully  considered  by  the  industrial 
world.  A  few  environments  have  been  developed  in 
large  European  project  such  as  PROSPECTRA  [12] 
and  are  ready  for  industrial  use. 

The  third  point  is  the  only  one  for  which  only  partial 
solutions  exist. 

Finally,  we  have  shown  that  algebraic  specifications 
could  be  successfully  used  within  spatial  domain  to 


describe  an  application  family  in  a  precise  and 
reusable  way.  Consecpiently,  we  can  think  we  have 
answered  Ihe  preoccupations  of  the  CNES. 

Annex 

Hereafter  we  briefly  expose  our  notations  about 
gencricity.  The  foundations  of  this  theory  can  be 
found  in  [4].  Since  it  increases  the  expression 
powerful,  it  has  been  integrated  in  most  of  present 
algebraic  specification  languages,  e.g  ACT  ONE  [4], 
Onj3  [7],  PLUSS  [2],  LPG  [1]  .. 

For  the  specifications  we  have  written,  we  have  used 
FP2  (Functional  Parallel  Programming.),  or  more 
exactly  a  subset  described  in  [8]  and  in  [9,  Annex  B] 
(This  generic  specification  language  includes  also 
some  aspects  of  parallelism  [13].) 

In  FP2,  parameter  specifications  are  expressed  by 
means  of  property  modules  The  types  and  operators 
introduced  inside  this  module  ate  given  after  the 
module  name,  e.g. — “/”  is  a  syntactic  separator 
between  types  and  operations — ■ 

Total-Order[t  /  rel,e?] 

where  t  is  any  totally  ordered  set,  rel  is  a  total  order 
relation,  and  eq  is  an  equivalence  one  (e^  is  needed 
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to  specify  the  antisymmetry  of  rel).  For  any 
instantiation,  the  lexical  order  is  used  to  substitute 
formal  parameters  by  actual  values,  e.g.: 

Total-Order[Nal  /  <,=] 

which  points  that  the  type  Nat  of  the  natural 
numbers,  equipped  with  the  boolean  operators  “<” 
and  “=”  is  a  totally  ordered  set. 

Three  types  which  appear  in  the  Satellite-Feature 
property  (cf.  Figure  2)  are  generic. 

•  The  fixed  arrays:  they  are  parameterized  by  the 
property  Ftype-and-Nat  which  comprises  the 
constituent  type  and  the  natural  number  which 
represents  tlie  dimension.  Thus,  the  expression: 

Fixed-Array. Fiype-and-Nat[Dit  /  10) 

denotes  the  fixed  arrays  whose  constituents  arc 
bits  and  dimension  is  10  (decimal  integers  arc 
allowed). 

•  In  the  same  way,  matrices  are  parameterized  by 
a  property  which  includes  the  constituent  type, 
the  number  of  rows,  and  the  number  of  columns, 
e.g.- 

Matrix. Ftyi>e-and-2-Nat[l}yte  /  32, 16) 

which  is  a  type  expression  used  for  specifying 
the  INTERBALL  telemetry  format. 

•  “Seq"  denotes  the  generic  sequences.  They  are 
parameterized  by  a  property  which  includes  one 
type.  Such  sequence  types  can  be  noted  in  an 
abridged  way,  e.g. 

(All  the  rules  about  the  conventions  for  these  type 
expressions  provided  by  FP2  can  be  found  in  (8)  ) 

Let  us  note  also  that  parameter  specification  can 
import  another  parameter  specification  by  means  of 
an  inclusion  mechanism,  as  exists  in  object-oriented 
languages.  (We  use  this  feature  in  Figure  2.) 
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SUMMARY 

This  paper  describes  work  on  mathematical  formal 
verification  of  a  redundancy  management  algorithm 
that  was  carried  out  in  two  stages.  The  first  stage 
used  the  specification  language  Z  and  veiified  the 
specifications  with  hand  written  ngorous  proofs.  The 
second  stage  used  a  proof  tool  to  producct  iormnl  proofs 
and  specified  the  system  with  the  language  of  that 
proof  tool.  The  system  specified  was  part  of  a  safety 
cntical  software  section  of  an  aviomc  system. 

The  paper  includes  a  section  that  presents  the 
theoretical  concepts  of  formal  methods,  concentrating 
on  specification  and  proof.  These  ideas  are  illustrated 
in  the  paper  with  extracts  from  the  formal 
specifications.  Some  of  the  benefits  and  problems  of 
using  mathematical  proof  for  verification  are  described 
in  the  illustration  of  the  redundancy  management 
example. 

INTRODUCTION 

This  paper  is  divided  into  two  main  sev'tions;  the  first 
on  theoretical  concepts  and  the  second  describing  the 
work  done  with  the  examples.  The  conclusions  of  the 
work  are  given  at  the  end  of  the  paper. 

The  first  section  of  the  paper  starts  by  defining  the 
terms  verification  and  validation.  It  continues  by 
describing  the  main  ideas  of  formal  methods:  formal 
languages,  formal  specifications,  formal  requirements, 
formal  refinement  and  proof 

The  second  section  of  the  paper  reports  on  the  two 
etagee  of  work  done  on  the  example  -  the  redundancy 
management  algorithm.  The  dUTerent  results  of  the 
stages  are  discussed. 

FORMAL  TECHNIQUES 

Validation  and  Verification 

Validation  and  verification  are  processes  that 
demonstrate  the  correctness  of  a  design.  However,  as 
there  are  many  definitions  of  these  terms,  the 
definitions  us^  in  this  paper  are  given  below. 

Validation  is  the  checking  of  a  desigi  against  the  real 
world:  does  the  system  performance  satisfy  the 
customei?  An  example  of  validation  is  the  inspection 
of  a  high  level  requirements  document.  The  ideas 
expressed  in  the  requirements  documents  are 
validated,  for  compliance,  against  the  customer's 
ideas. 

Venfication  is  the  checking  of  one  level  of  design 


against  another  level:  does  the  lower  level  of  design 
satisfy  the  requirements  of  the  higher  level  of  design? 
An  example  of  venfication  is  the  review  of  code 
against  a  low  level  design  document.  The  algorithms 
used  in  the  code  are  verified  against  tlie  algorithms 
required  by  the  low  level  design. 

Validation  of  a  detailed  low  level  design  is  often 
performed  in  two  stages:  verification  against  a  higher 
level  of  design;  and  then  validation  of  that  higher  level 
of  design.  This  is  done  because  validation  of  the  higher 
level  of  design  is  easier  as  the  requirements  are  not 
being  obscured  by  implementation  detail.  For  example 
consider  the  validation  of  code,  the  low  level 
specification,  using  pseudo  code,  the  high  level 
specification.  The  code  can  be  verified  against  the 
pseudo  code  by  review.  Thus  the  problem  of  validating 
the  code  directly  has  been  simplified  to  validating  the 
higher  level  pseudo  code. 

Thus  forma]  verification  is  used  to  show  the 
compliance  of  a  (detailed)  low  level  design  with  an 
(abstract)  high  level  document  that  can  itself  be 
validated  as  containing  all  the  important  properties 
required  of  the  system.  This  is  an  idea  that  will  be 
used  later,  with  the  levels  of  design  specified  formally 
and  the  verification  performed  with  mathematical 
proofs. 

Specification 

A  formal  specification  ie  a  description  of  the  design  of 
a  system  at  a  given  level  of  detail.  It  is  written  in  a 
language  with  a  mathematically  formal  definition  of 
both  the  syntax  and  semantics.  Examples  of  formal 
languages  are  VDM  or  Z  but  also  include  subsets  of 
most  programming  languages.  The  description  is 
usually  of  the  functional  aspects  of  the  system,  but 
may  include  non-functional  details  such  as  temporal 
requirements.  Tools  can  be  used  to  check  that 
specifications  obey  the  syntactic  rules  of  the 
Dpecification  language,  and  can  also  check  some  of  the 
semantic  rules,  such  as  type  matches.  The  levels  of 
design  that  are  specified  can  range  from  the  highest 
level  safety  requirements  down  to  the  executable 
program  code. 

'The  initial  advantage  of  formally  specifying  a  level  of 
design  IS  that  it  forces  choices  to  be  made,  and 
recorded,  about  unclear  aspects  of  the  design.  The 
formal  specification  itself  is  precise,  and  can  be  made 
abstract.  Precision  is  useful  as  it  removes  ambiguity  - 
all  the  choices  that  are  being  left  to  lower  levels  of 
design  are  made  clear.  Abstraction  ie  useful  in  high 
level  specifications,  as  it  allows  important  properties 
to  stand  out. 
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Where  two  levels  of  design  are  formally  specified  then 
formal  verification  techniques  can  be  used  to  encure 
that  one  is  a  correct  representation  of  the  other.  This 
leads  to  an  approach  where  successive  formal 
specifications  are  written,  and  each  is  checked  against 
its  predecessor.  This  approach  is  known  as  formal 
refinement  or  reification.  During  this  approach  the 
formal  specifications  of  the  design  becomes  more 
detailed  and  explicit  Thus,  the  abstract  requirements 
that  were  clear  in  the  high  level  specification  may  be 
obscured  by  this  detail.  Hence,  the  need  to  verify  the 
final  refined  design,  using  mathematical  proof,  against 
the  higher  level  designs. 

Proof 

Mathematical  proof  is  a  formal  verification  technique. 
It  can  be  used  to  show  that  one  mathematical 
statement  follows  logically  from  another.  Thus  it  can 
be  used  to  verify  that  a  low  level  formal  specification 
meets  a  high  level  formal  specification.  It  can  also  be 
used  to  help  validate  a  specification  showing 
mathematically  that  a  design  has  desired  properties. 
Proof  is  used  to  verify  that  the  specification  meets  this 
property;  then  the  mathematical  statement  of  the 
property  can  be  validated. 

A  mathematical  proof  can  be  presented  in  either  a 
rigorous  or  a  formal  style. 

A  rigorous  proof  is  an  outline  of  the  major  points  of  a 
proof.  It  should  provide  enough  detail  to  enable  a 
formal  proof  to  be  constructed.  However,  the  drawback 
with  rigorous  proofs  is  that  they  are  difficult  to  check, 
since  a  mathematician  is  needed  to  construct  the 
missing  steps  and  check  that  the  proof  is  correct 

A  formal  proof  has  all  the  details  of  the  proof  at  every 
stage  •  this  includes  the  proof  rules  used  and  the 


statements  they  were  used  on.  The  steps  of  a  formal 
proof  are  exceedingly  small  (such  as  the  rule  in  Figure 
1)  and  checking  is  a  simple  pattern  matching  exercise. 
This  can  be  carried  out  by  non-mathematicians  or  a 
simple  tool.  However,  because  of  the  extra  detail,  more 
effort  is  needed  initially  to  write  the  formal  proof. 

More  advanced  tools  can  help  write  proofs  by: 

•  Displaying  clearly  the  current  stage  in  the 
formal  proof. 

•  Applying  a  rule  chosen  by  the  user, 
calculating  the  next  stage  of  the  proof. 

•  Storing  a  library  of  rules,  to  aUow  the  user  to 
search  for  rules  that  may  be  useful. 

•  Let  the  user  define  new  rules  from  a 
combination  of  old  rules  and  store  these  in 
the  library. 

•  Allow  the  user  to  write  functions  that  try  sets 
of  rules  and  apply  them  if  they  are  usefiil. 

A  completed  proof  will  have  analysed  the  theorem  for 
every  possible  combination  of  inputs  and  states.  This 
car.  be  contrasted  to  testing  where  only  a 
representative,  finite  set  of  cases  is  analysed. 

However,  the  theorem  may  have  explicitly  excluded 
certain  cases,  and  the  analysis  with  proof  only  checks 
that  the  theorem  is  correct  in  the  cases  that  have  not 
been  explicitly  excluded. 

EXPERIENCE  OF  FORMAL  VERIFICATION 

Having  described  the  theoretical  ideas  behind  formal 
specification  and  proof,  the  paper  now  discusses  the 
formal  verification  of  an  example  redundancy 
management  algorithm. 


This  is  an  example  of  a  top-down  proof  rule.  The  rules  states  how  the  correctness  of  the  current 
goal,  above  the  line,  can  be  simplified  to  the  subgoal  below  the  line.  Each  goal  is  a  list  of 
hypothesis  and  a  conclusion:  the  goal  is  true  if  the  truth  of  the  hypothesis  entails  the  truth  of 
the  conclusion. 

In  the  rule  given  below,  B  and  C  are  general  predicates,  while  P  stands  for  all  other  predicates 
in  the  hypothesis  list.  The  rule  states  that  to  show  that  “if  the  hypotheses  in  P  are  true  then  the 
statement  S  =»  C  is  true”  it  is  sufficient,  because  of  the  rule,  to  show  that  “if  the  hypotheses  in 
P  are  true  and  B  is  true  then  C  is  true”.  The  rule  is  extremely  simple,  but  a  large  number  of 
such  rules  can  prove  useful  statements. 

Pi  B  =»  C 
P,SiC 

Figure  1:  Proof  Rule 
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Overview  of  System 

After  an  initial  study  of  formal  verification  on  a  small 
subsystem,  it  was  decided  to  apply  the  formal 
verification  techniques  to  a  much  larger  sub-system. 
The  initial  work  was  specified  in  Z  with  hand  written 
rigorous  proofs.  The  subsequent  work  used  a  proof  tool 
to  write  formal  proofs  and  specified  the  system  in  the 
language  used  by  that  proof  tool.  This  language  is 
bas^  on  the  functional  language  ML. 

Redundancy  management  of  duplicate  resources  is  an 
essential  part  of  many  safety-critical  systems,  and  this 
aspect  of  the  system  was  chosen  as  an  example  to 
study  the  results  of  formal  verification  techniques. 
Safety  critical  systems  are  viewed  as  a  natural 
application  area  for  formal  verification.  In  particular 
the  algorithms  used  in  safety  critical  systems  must 
also  be  considered  as  safety  critical,  and  it  is  the 
algorithm  that  the  formal  verification  was 
concentrated  on. 

With  the  benefits  of  the  initial  study  it  was  decided  to 
use  formal  verification  over  a  larger  area  of  the 
system,  to  specify  more  algorithms.  The  main  benefits 
expected  were  an  unambiguous  specification  of  the 
algorithm  and  better  analysis  of  the  algorithms  than 
testing  alone  can  provide. 

Redundancy  management,  as  the  name  suggests, 
chooses  between  redundant  elements  of  a  system  in 
the  event  of  failure.  The  illustrative  example  chosen  is 
a  tnplex  digital  system.  There  are  three  lanes,  each  of 
which  generates  commands  and  qualifiss  these 
commands  with  binary  flags.  Redundancy 
management  is  performed  by  the  comparison  of  these 
commands  togeAer  with  exchange  of  opimons  between 
lanes  on  the  correctness  of  the  other  lanes.  Ultimately 
these  opinions  can  cause  one  of  the  lanes  to  stop 
generating  commands.  It  is  the  function  that 
generates  these  opinions  that  we  have  specified  and 
validated,  and  it  is  clear  that  such  switching  of 
resources  is  critical  tu  the  safe  operation  of  the 
system. 

Overview  of  Procese 

Formal  verification  techniques  were  used  together 
with  informal  techniques,  important  parte  of  the 
algorithm  were  formally  specified,  and  an  informal  list 
of  specification  assumptiins  produced.  High  level 
requirements  were  stated  initially  as  broad 
mathematical  theorems.  These  were  modified  after 
analysis  to  provide  a  record  of  the  coveiage  of  the 
formal  verification. 


Specification 

The  specification  approach  employed  can  be  divided 
into  three  parts:  the  fi-amework,  the  requirements, 
and  the  algorithm.  The  fi'amework  and  algorithm  form 
the  main  specification,  describing  the  functional 
behaviour  of  the  redundancy  management  subsystem. 
The  requirements  are  of  the  higher  level  behavioural 
properties  that  are  desired  for  the  system.  For 
example  a  property  may  state  that  once  a  lane  has 
been  isolated  it  will  never  transmit  any  commands. 
Alternatively,  the  framework  and  requirements  can  be 
thought  of  as  a  high  level  specification,  and  the 
framework  and  algorithm  as  a  lower  level  refinement 
of  this  specification. 

The  specification  framework  describes  the  interface  of 
the  redundancy  management  subsystem  to  the  rest  of 
the  system.  This  includes  listing  the  variables  that  are 
input  and  output,  and  a  definition  of  their  types.  The 
framework  also  defines  how  the  inputs  and  outputs 
are  externally  linked  in  the  rest  of  the  system.  A 
simple  temporal  framework  is  also  defined  using 
functions  mapping  time  to  the  values  of  the  system 
states.  This  fi^mework  allows  the  sequences  of  the 
inputs  and  outputs  to  be  defined  and  can  be  used  to 
model  some  of  the  effects  of  the  asynchronous  aspects 
of  the  system. 

In  describing  the  structure  of  the  rest  of  the  system, 
abstractions  have  been  used  and  assumptions  made. 
Abstractions  are  used  to  hide  details  not  relevant  to 
the  redundancy  management  and  to  simplify  the 
system  to  make  analysis  easier.  For  example  the 
redundancy  management  does  .not  need  to  know  the 
exact  datatype  of  the  commands  it  is  comparing,  only 
that  the  commands  can  be  compared,  and  can  use  an 
abstract  datatype  with  this  property.  Also  there  are 
many  commands  that  the  redundancy  manageniert 
compares  but  abstractly  only  one  command  need  be 
described  and  the  results  of  the  analysis  of  the  one 
command  generalised  to  the  others. 

The  assumptions  that  had  been  made  in  the 
specification  were  recorded  and  form  part  of  the 
specification  document  The  assumptions  covered 
areas  such  as:  the  accuracy  of  the  temporal  model;  the 
generalisation  of  analysis  performed  on  one  to  the 
other  commands,  and  the  correctness  of  the 
simplifying  abstraction  used  on  the  datatypes.  An 
example  of  an  assumption  is  given  in  Figure  2. 


The  assumption  is  in  two  parts:  the  first  half  of  the  sentence  describes  the  assumption;  the  second  half  give 
some  justification  for  the  assumption.  This  will  be  reviewed  when  the  epecification  is  reviewed. 

“It  18  assumed  that  the  flags  A  and  B  can  be  modelled  as  a  single  boolean  value,  as  all  processes  use  the 
disjunction  (A  or  B)  of  the  flags.” 

Figure  2:  Example  Assumption 
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This  18  an  English  paraphrasing  of  a  Z  schema  that  describes  part  of  the  redundancy 
management  algorithm.  The  algorithm  is  defined  on  the  part  of  the  framework  describing  the 
inputs  and  outputs  of  a  lane.  This  information  is  contained  in  the  schema  6LaneState,  formally 
defined  elsewhere  in  the  specification.  The  A  symbol  is  the  standard  Z  notation  of  defining  an 
operation  with  two  copies  of  the  system  state:  one  is  used  to  represent  the  system  before  the 
operation,  the  other  represents  the  system  after  the  operation,  the  variables  of  the  state  after 
the  operation  are  shown  with  a  dash  after  the  variable  name.  The  operation  is  defined  by 
specifying  how  the  final  state  is  related  to  the  before  state 

It  can  be  seen  that  the  new  value  of  ownAfc,  that  is  ownAfc',  is  defined  explicitly  in  terms  of  the 
other  variables.  {OTHERLANE  has  only  two  values  so  the  forall  statements  can  be  simplified.) 
Thus  the  value  of  ownAfc'  can  be  calculated  from  the  inputs.  This  calculation  still  uses  abstract 
datatjrpes  and  operations  (operations  that  are  not  directly  available  in  programming  languages), 
such  as  the  relation  “does  not  compare  with”. 

rOwnAFCGeneration  — - - - — 

ALaneState 


ownAfc'  =  notAvadable  if  and  only  if 
(forall  lane  of  type  OTHERLANE* 

(inputs(lane)).dataSenf  =  sent  and  {inputs(lane)).afc  =  available  and 
threatToSelfflane)  =  threat)  or 
(forall  lane  of  type  OTHERLANE* 

(inpi'tsdane))  dataSent  =  sent  and  (inputs(lane)).afc  -  available  and 
(oldCommand,  ownCominand)  does  not  compare  with 
(inputs(lane)).command) 


Figure  3:  Specification  of  Design 


The  list  of  assumptions  was  found  to  be  useful  as  a 
checklist  to  be  used  when  the  specification  was 
reviewed.  As  the  specification  is  claimed  to  accurately 
model  the  system  apart  from  the  assumptions, 
validating  the  specification  can  concentrate  on  the 
closeness  of  the  model.  The  assumptions  can  be 
justified  informally,  complementing  the  formal 
analysis  that  is  validating  the  system. 

The  framework  is  written  from  informal  documents 
that  described  the  system,  and  validated  against  these 
documents  by  inspections. 

Tile  specification  of  the  algorithm  describes  the 
internal  operation  of  each  lane,  in  contrast  to  the 
framework  which  contains  the  external  links  of  the 
lanes  Together  with  the  framework  specification,  the 
algorithmic  specification  provides  a  complete 
description  of  the  aspects  of  the  system  that  are 
relevant  tc  the  redundancy  management  subsystem. 

The  algorithmic  specification  describee  how  the 
outputs  defined  in  the  framework  can  be  calculated 
from  the  inputs  defined  in  the  framework.  The 
algorithm  is  usually  defined  explicitly  but  still  uses 
abstract  datatypes,  such  as  lists  and  sets,  and  abstract 
operations.  ( An  example  of  part  of  an  algorithmic 
specification  is  given  in  Figure  3).  The  use  of  abstract 
datatypes  allows  the  algorithm  to  be  described  clearly 


and  concisely,  and  helps  with  the  reviewing  of  the 
specification.  The  explicit  natum  of  the  specification 
also  helps  reviewing,  and  allows  the  use  of  simple 
animations,  where  the  specification  is  translate  into 
a  very  high  level  programming  language  (e.g  ML  or 
Smalltalk)  and  executed. 

The  algorithm  is  formally  specified  from  an  outline 
given  in  an  informal  document.  One  of  the  benefits  of 
formal  specification  is  that  it  is  easy  to  see  the  cases 
that  have  been  left  out  of  the  informal  documents. 

As  with  the  framework,  a  list  of  the  assumptions  made 
in  formally  specifying  the  algorithm  is  written  down. 
This  list  of  assumption  is  very  useful  as  a  checklist 
because  it  includes  the  basic  assumptions  that  have 
been  mode  about  the  system  when  designing  the 
algorithm. 

Tlie  specification  is  used  as  a  requirements  document 
for  the  software,  the  lower  level  design  and  the  final 
code  can  be  verified,  formally  or  informally,  against 
the  specification 

The  algorithmic  specification  itself  is  validated: 
partially  by  formal  verification  against  the 
requirements  specification;  and  partially  by  review 
against  the  informal  descriptions  of  the  algorithms. 
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This  is  an  English  paraphrasing  of  a  Z  specification  of  a  requirement.  The  original  English 
requirement  was  "If  one  or  more  lanes  have  been  shut  down,  then  no  other  lane  will  be 
deliberately  shut  down." 

Note  that  the  specification  uses  some  previous  definitions;  LifeCycle  contains  the  state  of  the 
system;  NotTransmittingAfter  and  Shutdown  define  some  of  the  functions  used  in  the 
specification.  The  specification  is  very  precise  about  when  the  conditions  must  hold,  and  what 
they  must  be. 

- Requirements - 

LifeCycle 

NotTransmittingAfter 

Shutdown 


forall  frame  of  type  natural  number  and  laneNumber  of  type  LANEIDENT* 
laneNumber  notTransmittingAfter  frame  implies 
(forall  otherlane  of  type  LANEIDENT  and 
subseqFrame  of  type  natural  number  I 

otherlane  *  laneNumber  and  subseqFrame  >  frame* 
not  (otherlane  ehutdownOn  subseqFrame)) 


Figure  4.  Specification  of  Requirement 


The  requirements  specification  is  a  collection  of  high 
level  functional  requirements.  Many  of  the 
requirements  aie  fiindamental  to  the  safe  operation  of 
the  system.  The  requirements  are  defined  on  the 
inputs  ard  outputs  of  the  lanes  defined  in  the 
framework,  but  at  a  higher  level  of  abstraction  than 
the  algorithm  (eg  Figure  4).  Most  of  the  requirements 
include  a  set  of  conditions;  the  requirement  only 
applies  if  these  conditions  hold. 

The  requirements  are  written  functionally  with  two 
levels  of  functions.  The  higher  level  is  almost  a 
paraphrasing  of  an  informal  requirement,  and  uses 
the  lower  level  functions  to  link  the  inputs  and 
outputs.  The  conditions  for  the  requirement  are  also 
clearly  specified  at  this  level.  Thsn  the  lower  level 
functions  are  defined  to  give  an  exact  definition  This 
form  of  definition  is  used  to  help  validation  by 
separating  the  overall  requirements  from  the 
definitions  of  specific  terms. 

The  requirements  were  originally  written  from  the 
informal  high  level  philosophy  documents  and  after 
discussions  with  the  system  designers.  The 
requirement  were  later  modified  after  analysis  with 
mathematical  proofs.  The  modifications  added 
constraints  to  remove  cases  that  are  not  important  to 
the  operation  of  the  system  and  are  hard  to  prove.  The 
final  requirements  provide  a  clear  record  of  the  cases 
ihat  have  been  proved,  and,  in  the  constraints,  a  clear 
record  of  the  cases  which  have  not  been  proved.  When 
the  requirements  are  reviewed  the  exception  cases 
must  be  covered  by  informal  arguments. 


Proof 

Mathematical  proof  was  used  to  verify  that  the 
algorithmic  and  framework  specifications  met  the 
requirements  specification.  A  theorem  (a  mathematical 
statement  of  an  important  property)  was  written  for 
each  requirement  and  pro"cd  to  follow  from  the  lower 
level  specifications. 

For  the  initial  study,  which  had  been  written  in  Z, 
hand  written  rigorous  proofs  were  used.  The  proofs 
were  presented  in  a  formal  style  using  small  steps  to 
try  and  make  the  proofs  easy  to  check.  The  final  result 
was  a  proof  that  alternated  between  a  series  of  formal 
steps  and  rigorous  steps.  It  was  found  that  the  formal 
steps  were  very  tedious  to  check  by  hand,  and  the 
rigorous  steps  were  hard  to  check,  thus  the  confidence 
in  the  correctness  of  the  proofs  was  low. 

There  were  two  methods  to  increase  the  confidence  in 
the  proofs,  the  proofs  could  be  v  ritten  with  either 
fully  formal  steps,  or  large  rigorous  steps.  Fully  formal 
steps  would  allow  a  computer  aided  tool  to  check  the 
proof  Large  rigorous  steps  would  allow  a 
mathematician  to  check  the  proof 

As  a  computer  proof  tool  was  available  it  was  decided 
to  write  formal  proofs.  The  tool  has  a  number  of 
advanced  features,  including  tactics  which 
automatically  combine  simple  rules,  and  the  tool  has 
an  extensive  library  of  basic  rules.  The  proofs  were 
built  from  many  formal  steps  although,  as  many  of 
these  steps  were  chosen  automatically  by  the  tool, 
there  is  not  a  record  of  every  step.  Thus  the  record  of 
the  proof  has  a  rigorous  look  and  can  be  reviewed  by 
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mathematicians.  But  the  main  confidence  in  the  proof 
is  provided  by  renuming  the  proof  on  the  tool  using 
the  proof  records. 

One  of  the  benefits  of  using  proof  as  a  verification 
technique  was  that  before  writing  a  proof  the  author 
would  thoroughly  informally  analyse  the  theorem. 
This  would  often  lead  to  the  theorem  being  altered 
into  a  form  that  was  provable.  This  often  took  the 
form  of  defining  exceptional  cases  where  the  theorem 
does  not  apply.  The  proof  then  provided  evidence  that 
the  analysis  had  been  performed  and  checked  that  it 
was  correct. 

The  verification  of  the  algorithm  against  the 
requirements  is  complete  by  informally  justifying  the 
cases  that  have  been  exclude  by  the  theorem.  Either 
the  cases  are  so  unlikely  that  they  can  be  ignored,  or 
effects  that  are  lost  because  of  the  asstunptions  can  be 
used  to  show  the  correct  behaviour. 

CONCLUSIONS 

Overall  the  role  of  formal  verification  in  the  project 
can  be  thought  of  as  similar  to  that  of  the  role  of  the 
reinforcing  steel  rods  in  reinforced  concrete.  The 
formal  verification  is  very  strong  in  the  areas  it 
covers,  and  the  informal  analysis  gives  wide  coverage 
but  at  a  lower  level  of  confidence.  Together  the 


combination  of  formal  and  informal  analysis  gives 

higher  confidence  in  the  system. 

Specific  conclusions  from  the  study  of  formal 

verification  are: 

*  Formal  specification  produces  a  clear  precise 
description  of  the  system,  and  highlights  any 
ambiguous  parts  of  the  informal  description. 

*  A  list  of  assumptions  made  during  formal 
specification  is  useful  as  a  checklist  both  for 
the  formal  specification  and  the  original 
description. 

*  Formal  proofs  should  be  written  using  some 
tool  support.  Hand  written  proofs  should  be 
as  informal  as  possible  while  still  being 
rigorous. 

*  The  theorems  should  be  written  with  a  wide 
coverage  originally,  then  exceptions  added 
during  the  proof  stage.  These  exceptions  must 
be  informally  analy^. 

*  Proofs  ensure  that  the  algorithms  are 
analysed  thoroughly,  and  provides  a  good 
recoH  of  these  analysis. 
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SUMMARY 

This  paper  discusses  the  methodology  presently 
used  for  specification  and  development  of 
guidance  and  control  software  (GCS)  refered  to  as 
the  phased  approach.  This  methodology  is  shown 
to  present  basic  shortcomings  in  relation  with  the 
requirements  specification  phase:  long 
development  time,  reverse  engineering  tasks  and 
inadequat''  handling  of  errors. 

In  order  to  solve  these  problems,  a  new 
methodology,  the  simulation  based  approach,  is 
presented.  This  new  methodology  is  based  on  the 
fact  that  any  requirements  specification  for  control 
software  is  preceded  by  a  simulation  task,  that 
includes  the  design,  code  and  test  of  the  GCS.  As 
a  consequence,  the  GCS  is  developed  twice,  once 
in  the  simulation,  and  then  in  the  flight  software 

The  new  methodology  proposes  to  build  the  GCS 
only  once,  and  through  the  use  of  two  basic  tools: 
simulation  and  rapid  prototyping,  cuts  through  the 
main  shortcomings  of  the  phased  approach. 

1.  INTRODUCTION 

The  aim  of  this  paper  is  to  discuss  a  new 
methodology  for  specification  and  development  of 
guidance  and  control  software  (  GCS  ).  This 
methodology  is  based  on  the  fact  that  any  GCS  is 
built  upon  a  detailed  simulation,  which  includes  i- 
functionally  correct  version  of  the  GCS. 

This  methodology  was  tested  in  the  SBG  program 
(1|  and  IS  now  been  applied  to  a  subset  of  the 
EJ-200  DECU  (2),  in  parallel  with  the  phased 
approach  based  in  the  DOD-STO-2167A.  This 
software  is  actually  in  the  coding  and  unit  testing 
phase. 

The  new  methodology,  referred  to  as  simulation 
based  development,  proposes  as  a  core  principle  to 
reuse  the  GCS  built  for  the  simulation  into  the  real 
lime  target.  The  key  term  is  reuse.  If  the  GCS 
esisls  in  two  versions  functionally  identical,  one 
in  the  simulation  and  one  in  the  target,  and  both 
need  to  be  developed,  documented  and  maintained 
throughou:  the  life  of  the  equipment,  why  not  to 
produce  a  single  version  ? 

Advantages  are  numerous,  including  shorter 
development  time  ■  code  is  developed 
simulianeously  with  the  control  laws  -,  while 
disadvantages  are  minor. 

In  the  following  lines  we  will  present  more  in 
depth  those  ideas.  Section  2  will  discuss  the 
phased  approach  -  based  on  DOD-STD-2I67A  - 
used  for  the  complete  DECU  software  development. 

Section  3  will  present  the  simulation  based 
approach. 

Section  4  will  address  the  application  of  the 
simulation  based  approach  to  a  subset  of  the 
EJ-200  DECU  SW. 


2.  EJ-200  DECU  PHASED  APPROACH 

2.1  GENERAL 

The  EJ-200  DECU  is  a  digital  electronic  box, 
whose  function  is  to  control  the  EJ-200,  ihe  engine 
to  power  the  European  Fighter  Aircraf  (  EFA  ). 

The  DECU  software  is  in  the  flight  critical 
category  (  Level  1  SW  according  to 
RTCA/DO-178A  ). 

As  a  consequence,  a  set  of  stringent  software 
standards  have  been  built,  in  line  with 
UOD-STD-2167A.  This  specification  incorporates 
a  methodology  for  SW  development,  that  we  call 
the  phased  approach,  based  in  a  sequential  scries 
of  tasks;  spccificaiion,  design,  code  and  unit 
testing,  and  formal  testing. 

The  CASE  environment  is  based  on  EPOS  [3], 
which  includes  two  basic  tools;  EPOS-R,  used  for 
formulation  of  the  requirements,  and  EPOS-S, 
used  for  the  design  phase.  EPOS-R  is  a 
semi-formal  specification  language,  while  EPOS-S 
IS  a  formal  design  language,  EPOS-S  allows  for 
automatic  partial  generation  of  code.  Facilities 
such  as  requirements  tracing  or  consistency 
analysis  arc  included. 

Those  tools  will  not  be  discussed  further,  since 
their  exact  nature  is  incidental  to  the  new 
methodoly.  But  a  CASE  environment  is  an 
important  help,  since  requirements  traceability,- 
and  case  of  documentation  generation  is  a  must. 

2.2  PHASED  APPROACH  METHODOLOGY 

The  top  level  requirements  for  the  engine  control 
system  are  included  in  the  document  "  Engine 
Control  and  Monitoring  System  ”.  Requirements 
arc  expressed  in  purely  functional  terms,  for 
example:  "  Overshoot  shall  not  exceed  X%  of  the 
demand  ",  Actual  Control  Algorithms  (  CA  )  arc 
not  mentioned.  Preparation  of  this  document  docs 
not  require  a  prior  detailed  simulation  work.  It  is 
based  mainly  on  experience,  extrapolation  of  state 
of  the  art  techniques  and  equipments,  judgement 
and  conceptual  design. 

The  following  document  to  be  produced  is  the 
"  Electronics  System  Requirements  Document  " 

(  FRD  ).  This  document  not  only  includes 
functional  requirements,  but  also  all  the  CA 
defined  in  an  i  .formal  language.  It  cannot  be 
written  without  a  detailed  simulation  of  the 
engine,  its  sensors  and  actuators,  and  at!  the 
required  control  loops,  including  analogue  -  if  any 
■  and  digital.  It  is  the  last  contribution  of  systems 
and  control  engineering  to  the  development,  and 
from  it  the  software  engineering  phases  begin; 
Software  Requirements  Specification  (  SRS  ), 
Software  Design  Document  (  SDD  ),  etc. 

Let  us  study  how  the  Control  part  of  the  FRD  is 
built. 


Section  5  will  finally  present  the  conclusions. 


2.3  FRD  GENERATION 


The  process  of  producing  Ihe  control  part  of  the 
FRD  IS  as  follows;  The  engine,  its  sensors  and 
actuators  are  modelled  to  a  level  of  accuracy 
which  is  a  compromise  between  fidelity  and  time  - 
both  c.xocution  and  development  From  this 
simulation  a  series  of  lineal  or  at  least  simplified 
sets  of  equations  arc  derived,  and  from  those  the 
CA  arc  designed.  They  arc  then  coded,  tested  and 
refined  within  the  simulation.  Once  a  satisfactory 
solution  is  found,  the  CA  arc  translated  from  the 
simulation  to  the  FRD. 

So,  the  task  of  producing  the  control  part  of  the 
FRD  can  be  itemised  as  follows; 

•  Simulation  build  up. 

•  An  iterative  process  of  design,  code  and  lest 
of  the  CA  until  an  adequate  solution  is  found 
within  the  simulation. 

•  A  reverse  engineering  process,  through  which 
we  transform  the  GCS  in  the  simulation  into 
requirements  in  the  FRD. 

This  process  implies  translating  a  formal  language 
( the  simulation  code  )  into  an  informal  one  (FRD 
requirements  ).  Thus,  we  obtain  the  result  that  the 
very  formal  and  apparently  elegant  methodology 
of  the  phased  approach  for  software  development 
is  III  fact  based  on  a  reverse  engineering  process. 
The  document  to  be  obtained  in  the  first  phase  of 
the  dcvclopriU’ni,  the  FRD,  must  be  preceded  by 
Ihe  design,  code  and  test  of  the  same  software  we 
arc  trying  to  obtain. 

And  this  result  not  only  applies  for  development. 

It  IS  also  required  for  software  maintenance.  If  any 
control  characteristics  arc  to  be  modified  during 
the  life  of  the  engine,  those  arc  first  tested  in  the 
simulation  environment,  and  so  the  CA  have  to  be 
coded  before  the  new  requirements  arc 
incorporated  into  the  FRD. 

2.4  PHASED  APPROACH  APPRAISAL 

The  phased  approach  to  SW  development  was  a 
mi.jor  improvement  when  it  was  introduced  some 
fillccn  years  ago,  and  has  increased  considerably 
software  quality.  Nonetheless,  in  the  case  of 
control  SW.  it  has  several  shortcomings.  The  main 
ones  we  have  identified  arc; 

•  The  simulation,  which  is  the  basis  o'"  the 
control  requirements  within  the  FRD,  is 
usually  developed  with  a  set  of  software 
standards  well  below  those  of  the  flight  code. 
The  result  is  a  significant  risk  of  an  error 
been  introduced,  either  in  the  simalatioii  of 
the  engine,  the  accesorics,  the  environment, 
etc,  cither  in  the  CA  themselves.  The 
complexity  of  the  configuration  control  in 
this  kind  of  program  increases  the  chance  of  a 
simulation  induced  error  taking  place. 

•  Lenghtly  development  times.  The  CA  have  to 
be  transformed  into  software  at  least  twice  ( 
in  the  simulation  and  in  the  embedded 
software  ). 

•  Some  errors  which  can  be  introduced  early  in 
(he  development  process  can  only  be  detected 
III  Its  very  late  stages,  creating  potential 
ha/.ards.  We  cal!  those  errors  open  loop 
errors,  due  to  the  following; 


-  In  the  phased  approach,  part  of  the 
development  is  tied  up  within  a  closed 
loop;  the  code  produced  can  be  tested 
against  its  requirements,  and  as  a  result 
any  error  introduced  from  the  SRS 
downwards  will  be  detected  and 
eonsequcntly  corrected  before 
hardware-softw.ire  integration. 

-  Open  loop  errors  are  those  introduced  when 
producing  the  FRD  or  the  SRS.  They 
cannot  be  correcicu  in  the  SW  tests, 
whatever  the  severity  of  those  mighi  be. 
They  can  only  be  foind  in  the  system  tests, 
after  hardware-software  integration.  The 
phased  approach  docs  not  provide  any  idea 
on  how  to  solve  the  open  loop  errors, 
except  to  look  for  them  in  the  system  tests. 
This  solution  is  inadequate  from  a  program 
point  of  view,  since  the  cost  of  correcting 
an  error  increases  as  an  exponential 
function  of  the  time  it  takes  to  be  found. 

•  Open  loop  errors  not  only  exist  in  the  phased 
approach,  since  for  example  any  error  in  the 
modelling  of  the  engine  might  lead  to  it  under 
any  development  methodology.  But  the 
phased  approach  has  a  tendency  to  increase 
them  through  two  effects; 

-  The  phased  approach  results  in 
requirements  expressed  in  a  formal 
language  in  the  simulation  (  Fortran  for 
example  ),  being  translated  into  an 
informal  one  in  the  FRD,  and  then  back 
again  into  a  different  formal  language  ( 
specification  language  )  in  the  SRS.  Those 
conversions  arc  a  high  risk  area. 

-  The  phased  approach  docs  not  provide  any 
mean  for  checking  simulation  CA,  FRD  and 
SRS  consistency  before  hardware-software 
integration. 

3.  SIMULATION  BASED  APPROACH 

The  simulation  based  approach  places  some 
requirements  on  the  development  of  the  simulation 
Itself.  We  will  study  those  in  the  first  place,  and 
then  we  will  proceed  to  the  flight  SW  development. 

3.1  SIMULATION  R.EQU1REMENTS 

The  simulation  includes  at  least  two  different 
Computer  Software  Configuration  Items  (  CSCI  ). 
The  first  one,  which  we  will  discuss  in  length 
thereafter,  and  includes  the  GCS,  is  the  ”  common 
simulation-embedded  SW  The  second  one, 
which  we  call  "  other  simulation  SW  ",  contains 
everything  else,  and  is  made  up  by  the  following 
Computer  Software  Components  (  CSC  ); 

•  CSCI;  Environment  (  atmosphere,  engine  and 
accessories,  including  hardware  of  the 
electronic  box,  etc  ). 

•  CSC2;  Simulation  of  the  embedded  SW  non 
included  in  the  CSCI  "  common 
simulation-embedded  SW  ",  This  CSC  is  very 
dependent  on  the  extension  of  the  CSCI  " 
cominom  simulation-embedded  SW  ",  and  in 
the  limit  it  can  be  reduced  to  a  simulation  of 
the  run-time  system  of  the  electronic  box.  In 
most  cases  it  will  also  include  hardware 
dependent  features,  such  as  the  drivers  and 
the  Built-in-Test  (  BIT  ).  If  the  CSCI  " 
common  simulation-embedded  SW  "  is 
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reduced  as  much  as  possible,  it  will  include 
everything  except  the  GCS,  as  for  example 
the  input  signal  conditioning  or  the 
supervisory  logic. 

•  CSC3:  Analysis  tools.  Those  tools  help  the 
developer  in  its  use  of  the  simulation,  and 
includes  elements  such  as  data  presentation, 
noise  evaluation,  transfer  functions 
identification,  statistical  data  analysis,  etc. 

The  requirements  for  the  CSCI  ”  other  simulation 
SW  ”  are  as  follows: 

•  It  should  be  considered  as  a  Level  2  software 
according  to  RTCA/DO-178A.  This 
requirement  comes  from  the  fact  that  errors  in 
the  embedded  code  due  to  simulation 
inadequacies  can  only  be  detected  in  the  test 
bed  trials  with  a  real  engine.  The  costs  -  due 
mainly  to  program  delays  -  generated  by  such 
late  errors  can  be  considerable,  and  arc  best 
avoided  by  raising  the  simulation  quality. 

<  CSCI  (  environment  simulation  )  shall  be 
developed  with  the  aim  of  been  as  complete 
as  possible.  This  results  in  two  favourable 
effects:  on  one  hand,  the  GCS  can  be  tested 
in  a  more  realistic  environment,  and  the  side 
effects  not  usually  accounted  for  can  be 
explored.  On  the  other  hand,  the  CSCI  " 
common  simulation-embedded  SW  “  can  only 
be  made  larger  if  the  environment  expands 
itself  accordingly.  For  example,  the  BIT  can 
only  be  including  in  the  ”  common 
simulation-embedded  SW  "  if  the  hardware 
failures  arc  simulated  in  the  CSCI. 

Requirements  for  the  CSCI  "  common 
simulation-embedded  SW  "  arc  different.  It  is  to 
be  line  to  line  identical  in  the  simulation  and  in 
the  embedded  SW.  It  shall  be  built  to  the  same 
standards  as  the  flight  SW,  and  its  documentation, 
configuration  control  and  quality  evaluation  arc 
directly  applicable  to  the  flight  SW. 

In  fact,  until  the  point  where  hardware-software 
integration  begins,  development  of  this  CSCI  for 
both  the  simulation  computer  and  the  flight 
computer  is  only  one  activity.  From  now  on,  we 
will  consider  it  as  a  flight  SW  task,  its  use  for  the 
simulation  been  just  a  by-product.  I.et  us  proceed 
into  how  this  SW  is  developed. 

3.2  FLIGHT  SW  DEVELOPMENT 

The  embedded  SW  is  made  up  of  two  CSCI.  The 
first  one  has  already  been  mentioned,  it  is  the  " 
common  simulation-embedded  SW  ",  and  includes 
the  GCS.  The  other  CSCI  is  "  other  embedded  SW 
’,  and  is  made  up  of  all  SW  modules  not  contained 
in  the  first  one.  It  includes  at  least  the  run-time 
system,  and  probably  the  drivers,  SW  related  to 
IIW  such  as  BIT,  and  in  general  all  SW  not 
developed  nor  tested  with  the  help  of  the 
simulation. 

The  CSCI  "  other  embedded  SW  "  is  to  be 
produced  according  to  the  rules  of  the  phased 
development  approach,  and  in  particular 
DOD-STD-2167A.  The  new  methodology  does  not 
introduce  in  it  any  modification,  except  the 
requirement  that  each  embedded  box  SW  has  to 
have  at  least  two  CSCI,  one  developed  within  the 
simulation  and  the  second  external  to  it. 


The  development  of  the  CSCI  "  common 
simulation-embedded  SW  "  implies  a  new 
methodology.  Two  aparently  opposite 
requirements  are  to  be  met  (  see  ref  [3)  ): 

•  SW  should  be  generic  enough  such  that 

<  nar.ges  typically  required  by  control  design  ( 
gain  modifications,  inclusion  or  elimination 
of  a  specific  feddback  variable,  etc  )  could  be 
easily  implemented. 

•  SW  should  be  adequate  for  a  real  time 
application.  This  usually  implies  elimination 
of  unnecessary  operations,  such  as 
multiplication  by  zero. 

The  main  difficulty  is  of  course  not  only  to  solve 
those  requirements,  but  to  develop  control  SW 
according  to  class  1  standards  without  a  well 
defined  FRD  to  begin  with. 

Our  answer  has  been  to  develop  an  iterative 
process,  which  can  be  detailed  as  follows: 

•  All  the  SW  development  process,  from  FRD 
to  CSCI  testing,  is  redone  continuously,  with 
a  new  SW  issue  been  produced  every  few 
weeks. 

•  Each  issue  is  formaly  developed  in  the  sense 
that  changes  arc  first  introduced  at  FRD 
level,  and  then  implemented  down  through  all 
the  stages  of  the  phased  approach  until  CSCI 
testing.  All  basic  documents:  FRD,  SRS,  and 
SDD  are  kept  in  EPOS  and  arc  traceable. 

•  SW  IS  divided  into  two  different  areas:  code 
itself  and  what  we  call  "  initial  parameters " 
i.e.,  initialisation  values  of  control  and  logic 
variables.  Those  arc  kept  within  an  assigned 
memory  area,  and  can  be  modified  without 
reissuing  the  SW  itself.  In  this  way  the 
system  engineers  can  modify  the  control  laws 
without  continuously  changing  the  SW.  The 
value  of  those  '  initial  parameters  "  allows 
not  only  to  change  the  numeric  value  of 
gains,  limits,  etc,  but  also  to  feedback  or  not 
any  specific  variable,  or  to  switch  from  a  PI 
feedback  to  a  PID,  etc. 

•  Every  SW  issue  has  an  original  set  of  values 
for '  initial  parameters  '  which  is  subject  to 
configuration  control.  Changes  made  to  these 
parameters  within  each  issue  are  not  subject 
to  configuration  control,  and  are  only 
recorded  through  technical  notes.  Those 
might  lead,  when  consolidated,  to  a  change 
request  incorporated  into  the  following  FRD 
issue. 

This  iterative  process  is  in  our  opinion  within  the 
spirit  of  DOD-STD-2167A.  which  in  its  foreword 
explicitely  states  that "  The  contractor  is 
responsible  for  selecting  software  development 
methods  (  for  example,  rapid  prototyping  )  that 
best  support  the  achievement  of  contract 
requirements  ". 

The  iterative  activity  we  have  jusi  described  is 
performed  by  two  work  teams.  The  first  one  is 
made  up  by  an  agregate  of  different  specialists: 
system  and  control  engineers,  fluidodynamicists 
and  safety  experts.  Their  first  task  is  to  prepare 
the  preliminary  issue  of  the  FRD.  From  then  on, 
they  receive  the  succesive  issues  of  the  SW,  test  it 
with  different  values  of  the  "  initial  parameters  " 
and  prepare  the  following  revisions  of  the  FRD. 
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The  second  team  is  made  up  of  software  engineers 
who  prepare,  as  in  the  phased  approach,  the  SW 
itself  Due  to  the  CASE  tools  used,  an  important 
part  of  this  task  is  done  automatically,  once  the 
first  SW  version  is  implemented. 

3.3  SIMULATION  APPROACH  APPRAISAL 

The  simulation  approach  methodology  for  control 
SW  solves  most  of  the  shortcomings  we  found  in 
the  phased  approach.  Its  advantages  are  as  follows: 

•  Simulation  induced  errors  decrease,  as  more 
development  effort  is  put  into  this  tool.  This 
result  is  important  since  those  errors  tend  to 
be  expensive  to  solve,  as  they  appear  only  in 
the  tests  with  the  real  engine. 

•  Open  loop  errors  generated  when  translating 
simulation  GCS  to  the  FRO  and  then  to  the 
SRS  arc  eliminated,  since  the  flight  SW  is 
tested  with  the  simulation  from  the  initial 
stages  of  the  program.  The  only  errors  that 
can  survive  undetected  through  SW  testing 
arc  those  due  to  simulation  inacuracies  and 
errors  found  in  the  CSCI  "  other  embedded 
SW  ". 

•  Development  time  decreases,  due  to  a 
combination  of  factors; 

-  Flight  SW  prototypes  are  available  very 
early  in  the  program. 

-  Less  errors  arc  produced,  specially  those 
lengthly  to  solve. 

-  ’’Tic  CSCI  "  common  simulation-embedded 
SW  ”  is  only  produced  once. 

This  approach  has  also  several  shortcommings. 
Those  we  have  found  are  the  following: 

•  As  more  quality  is  required  from  the 
simulation,  more  effort  has  to  be  put  into  it. 

•  The  very  formal  procedure  for  producing  the 
CSCI  "  common  simulation-embedded  SW  " 
even  before  the  CA  are  well  defined  might 
appear  as  a  disproportionate  effort. 

•  The  embedded  SW  produced  maintains  some 
characteristics  of  simulation  SW  and  is  not 
optimized  from  an  execution  time  point  of 
view. 

From  our  experience,  advantages  arc  considerably 
more  important  than  disadvantages.  In  fact,  .some 
effects  which  might  appear  as  shortcommings  have 
also  favorable  aspects.  For  example,  the  fact  that 
the  embedded  SW  retains  some  characteristics  of 
the  simulation  SW  implies,  among  other  things, 
that  it  is  easier  to  modify  than  typical  flight  SW. 
This  might  prove  of  considerable  advantage  during 
the  life  of  the  engine. 

4,  APPLICATION 

This  methodology  has  been  applied  to  a  small 
subset  of  the  EJ-200  DECU,  the  control  of  the 
Mam  Metering  Valve  (  MMV  )  of  the  Main  Fuel 
Metering  Unit  (  MFMU  ).  The  following  steps 
where  followed: 


•  An  initial  FRD  for  the  MMV  was  written. 

•  The  interface  definition  between  the 
simulation  SW  and  the  "common 
simulation-embedded  SW  "  was  defined. 

•  As  the  simulation  was  coded  in  Fortran,  and 
the  ”  common  simulation-embedded  SW  "  was 
in  ADA,  a  pragma  construct  was  implemented. 

The  first  version  of  the  "  common 
simulation-embedded  SW  "  was  produced  and 
running  before  the  initial  FRD  for  the  complete 
DECU,  using  the  EJ-200  SW  standards  was 
written.  An  up  to  date  version  was  in  place, 
documented  and  tested  during  the  SRS  phase. 

Changes  were  easily  introduced  into  the  MMV 
FRD,  such  as  those  required  by  reliability 
considerations.  The  MMV  SRS  went  through 
further  improvements,  such  as  eliminating  real 
number  multiplications,  or  more  detailed 
interfaces  definition.  An  important  result  was 
nonetheless  negative,  as  we  found  that  developing 
through  the  new  mcth'idology  a  small  subset  of  a 
CSCI  was  impractical,  since  many  general  purpose 
procedures  (  such  as  table  interpolation,  for 
example  ),  not  originally  interned  to  be  part  of  the 
module  had  to  be  incorporated  in  it,  as  those 
modules  where  not  yet  available. 

On  the  other  hand,  we  found,  as  expected,  that  the 
GCS  development  time  could  be  considerably 
reduced. 

Another  important  result  was  that  the  simulation 
task  Itself,  though  much  more  formal  than  in 
previous  programs,  was  not  slowed  down,  and  it 
even  seemed  to  be  actually  faster.  One  possible 
interpretation  is  that  the  system  engineers,  been 
freed  from  the  software  task  of  building  the 
simulation,  could  concentrate  on  the  control 
algorithms  themselves. 

5.  CONCLUSIONS 

The  main  results  we  have  obtained  are  as  follows;' 

•  In  the  phased  approach  development 
methodology  for  control  software,  the  FRO  is 
the  result  of  a  reverse  engineering  process: 
from  simulation  to  requirements. 

•  In  the  phased  approach  development 
methodology,  any  error  produced  when 
translating  the  FRD  into  the  SRS  or  before, 
will  not  be  found  until  the  real  time 
simulation  test  takes  place,  or  even  later. 

•  Embedded  SW  can  be  split  into  two  CSCI; 
one  of  them,  which  includes  the  GCS,  can  be 
developed  through  a  new  methodology  which 
we  have  called  simulation  based  approach. 

•  The  simulation  based  approach  uses  a 
common  SW  in  the  simulation  and  in  the 
flight  computer. 

«  The  simulation  based  approach  has  two  basic 
advantages  over  the  phased  approach:  shorter 
development  time  and  avoidance  of  most  open 
loop  errors. 
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NETWORK  PROGRAMMING: 

A  DESIGN  METHOD  AND  PROGRAMMING  STRATEGY 
FOR  LARGE  SOFTWARE  SYSTEMS. 
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Neuenahrer  Str.  20, 

Summary:  Network  Programming  is  a 
methodology  for  the  evolutionary  develop¬ 
ment  and  life  cycle  support  of  large  data 
processing  systems.  It  utilizes  a  fully  decen¬ 
tralized  approach.  A  given  DP  task  is  first  re¬ 
alized  as  an  operable  network  of  sequential 
processes,  communicating  via  typed  chan¬ 
nels.  It  serves  as  a  base  for  logical  testing, 
data  flow  measurements,  and  assessment  of 
system  behaviour.  Runtime  requirements 
and  the  mapping  of  processes  to  processors 
are  taken  care  of  in  a  separate  final  step.  A 
remote  procedure  call  illustrates  the  concept 
of  a  channel’s  operation  mode.  The  Network 
Programming  method  is  neither  confined  to  a 
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certain  programming  language  nor  to  a  cer¬ 
tain  kind  of  machinery.  Here  we  will  first 
give  a  short  introduction  to  Network  Pro¬ 
gramming  and  its  main  features.  Then  the 
Network  Programmer's  Workbench  will  be 
shown  in  some  detail  and  some  of  its  tools 
will  be  described.  Particular  attention  will  be 
paid  to  the  Network  Monitor.  An  example 
will  illustrate  the  use  of  these  software  instru¬ 
ments.  Finally,  we  will  have  a  look  on  a  de¬ 
fense  oriented  simulation. 

Keywords:  evolutionary  software  develop¬ 
ment,  communicating  sequential  processes, 
typed  channels,  OSI  application  layer.  Net¬ 
work  Monitor. 


1.  The  situation  to  cone  with 

Systems  for  guidance  and  control  arc  fre¬ 
quently  integrated  systems  with  heterogene¬ 
ous  components.  Software  makes  the  indi¬ 
vidual  components  accessible  by  describing 
their  interface,  and  software  makes  them 
communicate,  thus  describing  the  essence  of 
the  system.  Software  for  guidance  and  con¬ 
trol,  embedded  software,  for  short,  is  there¬ 
fore  of  considerable  complexity.  We  focus 
our  contribution  on  large  software  systems  of 
this  kind,  which,  in  addition,  have  a  long  pe¬ 
riod  in  service. 

Large  software  systems  are  subject  to  chaig- 
es:  of  the  machinery  involved,  or  changes  in 
requirements,  or  of  design  goals.  Those 
changes  take  place  usually  and  should  be  tak¬ 
en  account  of  from  the  very  beginning  of  a 
project.  Network  Programming  (NWP)  is  a 
method  to  construct  large  software  systems 
upon  autonomous  communicating  processes. 
NWP  helps  to  cope  with  all  three  kinds  of 
changes  because  it 


♦  supports  the  implementation  of  well- 
defined  processes, 

•  allows  processes  written  in  different 
languages  to  communicate  effectively, 

♦  makes  processes  communicate 
effectively,  which  run  on  different 
machines  under  different  operating 
systems  and 

•  supports  changing  programs,  adding 
processes  to  the  system,  and  removing 
processes  from  the  system  at  minimal 
costs  in  terms  of  implementation  and 
test  times. 

The  concept  of  Network  Programming  has 
been  outlined  in  [1].  Basic  work  and  an  im¬ 
plementation  have  been  reported  in  [2].  It 
could  easily  be  used  in  defense  oriented  sim¬ 
ulations  as  described  in  [3].  As  a  develop¬ 
ment  tool  for  greater  systems  was  needed,  an 
Ada  -  oriented  workbench  had  been  devel¬ 
oped  [4].  The  use  of  Network  Programmer’s 
Workbench  to  design,  implementation,  and 
test  of  process  networks  is  described  in  [5]. 
In  this  contribution,  the  main  concept  is  de- 
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autonomous  processes 


Figure  1:  NWP  inventory 

rived  from  certain  needs  when  programming 
large  systems. 

2.1  Modular  Programming:  distribution  of 
workload  upon  dedicated  machines 

It  is  a  commonplace  idea  to  distribute  parts  of 
a  complex  task  to  pieces  of  hardware,  which 
each  matches  best  the  details  of  work  to  be 
performed.  In  reality,  i.e.  in  our  context  of 
guidance  and  control,  systems  get  composed 
of  suitable  hardware,  and  are  to  be  glued  to¬ 
gether  by  means  of  software,  later  on.  It  is 
conceptually  no  great  step  to  imagine  tasks, 
completely  separated  one  from  the  other, 
which  communicate  by  rather  simple  mes¬ 
sages.  Each  task  may  be  written  in  its  proper 
programming  language,  i.e.  that  optimal  me¬ 
dium  to  describe  and  effectively  attain  the  in¬ 
dividual  portion  of  the  general  aim. 


typed  channels 


2.2  Communicating  processes  by 
mes.:age  passing 

We  regard  systems  as  composed  of  processes 
and  directed  channels  (Fig.  1)  resulting  in  a 
process  network,  which  can  be  represented  as 
a  system  communication  graph  (Fig.  2). 
Each  process  executes  sequentially  and  in 
mutual  independence.  Currently,  it  may  be 
described  in  e.g.  Ada,  Pascal,  C,  or  Prolog. 
Other  languages  may  be  included  by  writing 
an  interface  in  that  language  and  linking  it  to 
the  application  programs. 

Each  channel  connects  at  least  one  process  to 
at  least  another  one.  It  transmits  messages  of 
a  certain  type  or  of  some  corresponding  struc¬ 
ture.  The  senders  and  receivers  on  both  ends 
of  each  channel  command  co-operatively  the 
message  transfer  and  must  agree  upon  that 
message  type  or  structure  (e.g.  cf.  Figure  5). 


Figure  2:  System  communication  graph 
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Figure  3;  Channel  as  a  typed  buffer 


The  channels  are  buffers  connecting  the  re¬ 
spective  communication  partners.  Depend¬ 
ing  on  buffer  management,  there  are  three 
connection  modes  to  be  distinguished; 

•  synchronous  mode  (S  mode),  buffer  is  a 
0-element  queue,  the  sender  waits  for 
receiver; 

•  buffer-synchronous  mode  (BS  mode), 
buffer  is  a  k-element  queue  (cf.  Fig.  3), 
the  sender  fills  up  the  buffer  without  hes¬ 
itation  and  then  waits  until  at  least  one 
clement  has  been  removed  (read  out)  by 
a  receiver, 

•  asynchronous  mode  (AS  mode),  the  buff¬ 
er  contains  one  element,  which  may  be 
overwritten  by  the  sender. 


This  approach  induces  the  concept  of  a  sepa¬ 
rate  manager:  Local  Communication  System 
(LCS),  to  create  and  maintain  the  communi¬ 
cation  ways  between  the  processes,  to  furnish 
these  channels  with  appropriate  buffer  capac¬ 
ity,  and  to  establish  the  necessary  translation 
between  language  interfaces.  Regarding  the 
last  point,  we  ultimately  split  the  manager. 
Each  process  contains  a  language-dependent 
part,  which  U’ansforms  language-dependent 
communication  calls  to  a  common  communi¬ 
cation  interface.  This  part  of  a  process  com¬ 
municates  with  the  LCS  and  hands  messages 
to  and  fro. 

The  communication  between  different  ma¬ 
chines  takes  place  as  message  passing  by 
means  of  the  respective  operating  systems 
between  the  LCSes  involved  (Fig.  4). 


Figure  4:  LCS  -  process  connections 
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2.3  An  example:  simulating  RPC 

Nowadays’  operating  systems  comprise  re¬ 
mote  procedure  call  (RPC)  facilities,  and  oth¬ 
er  means  to  make  processes  communicate. 
Fig.  5  illustrates  the  simulation  of  a  remote 
procedure  call  by  means  of  NWP  features  and 
their  corresponding  Ada  constructs.  The 
complete  listings  will  be  given  in  the  appen¬ 
dix.  The  lower  part  of  Fig.  5  shows  the  re¬ 
spective  transport  commands  and  their  line 
numbers  in  these  Ada  listings. 

The  subsequent  series  of  Monitor  pictures  il¬ 
lustrates  a  process  network  with  one  server 
and  three  clients  under  different  aspects: 


The  network  is  spread  over  tiiree  ma¬ 
chines,  the  server  and  one  client  reside  on 
SUN  workstation  "rspsunl4",  while  the 
two  other  clients  run  on  different  SUN 
workstations,  each. 

The  clients  use  the  channel  in  synchro¬ 
nous  mode,  the  access  is  "give_wait". 
Oient_14  has  given  a  message,  which  the 
server  has  not  taken,  yet. 

Another  state;  client_12  has  delivered  a 
message,  which  has  not  yet  been  accept¬ 
ed,  the  flow  is  52/22  messages  per  sec¬ 
ond. 

The  other  channel  ist  FROM_SERVER, 
it  displays  again  the  networks 
distribution. 


Client; 

40  ’c.GIVE(  TO.SERVER.ORDER  ); 

42  C.TAKE(  FROM_SERVER.RESULT.SENDER ); 

loop 

S.TAKE(  TO_SERVER, ORDER );, 

S  GIVE{  FROM_SERVER, RESULT ); 
end  loop 


Server; 
•iiii"  32 

-  37 


Figure  5:  RPC  Simulation 


Environment  of  channel  *T0_SERVER* 


19 


52  Messages  in  22  seconds 


Figure  6:  The  channels  TO_SERVER  (above)  and  FROM_SERVER  (below)  and 
their  respective  environments,  access  modes,  and  buffer  repletion. 


14-6 


2.4  Systems  with  different  machines  under 
different  operating  systems 

The  same  idea  applies  when  no  common  op¬ 
erating  system  or  system  family  can  be  as¬ 
sumed:  Given  a  transmission  control  proto¬ 
col,  the  LCSes  must  adopt  the  greatest  com¬ 
mon  portion  of  the  protocols  shared  by  the 
different  machines.  Our  experience  compris¬ 
es; 

•  processes  on  different  SUN  workstations 
under  UNIX 

••  written  in  the  same  programming  laguage 
( Pascal,  or  C,  or  Ada,  or  Prolog ) 

••  written  in  different  programming  lan¬ 
guages  ( Pascal,  and  C,  and  Ada,  and 
Prolog) 


3.  Support  environment: 

the  NWP  programmer’s  workbench 

Nowadays’  operating  systems  contain  virtual 
file  systems,  remote  procedure  call  facilities, 
and  other  means  to  make  processes  commu¬ 
nicate.  Thus  they  fulfill  OSI  specifications 
on  the  application  layer  and  encourage  the 
development  of  distributed  data  processing 
applications.  To  strengthen  this  gradient  of 
development  is  one  purpose  of  Network  Pro¬ 
gramming. 

Frequently,  the  partition  of  work  is  a  major 
point  of  concern,  be  it  not  to  loose  human 
control  or  understanding,  be  it  to  apply  spe¬ 
cialized  hardware,  or  to  avoid  waiting  situa¬ 
tions.  If  a  large  system  is  composed  of  well 
fit  hardware  to  fulfill  the  partitions  of  task,  it 


Figure  7:  A  heterogeneous  network  example 


and 

•  processes  on  SUN  workstations  under 
UNIX  and  on  DEC  VAX780  under  VMS 
••  written  in  VAX-Ada  and  using  the 
VERDIX  Ada  Development  System, 

they  all  communicate  by  message  exchange. 
Fig.  7  shows  as  example  a  machine  configu¬ 
ration  in  operation  at  our  site. 


may  occur  that  in  "typical"  situations  individ¬ 
ual  components  are  overloaded  and  their 
companions  have  already  finished  their  part 
and  must  wait.  Probably  the  duplication  of 
one  dedicated  piece  of  hardware  would 
speed-up  the  overall  performance,  or  to  apply 
another  kind  of  algorithm,  or  to  build  in  an¬ 
other  switch  to  discriminate  types  of  situa¬ 
tions  or  of  workload.  TTie  analogue  may  arise 
under  conditions  near  the  limit  of  a  system’s 
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area  of  applicability:  in  the  very  beginning,  or 
near  system  overload,  or  due  to  damages.  In 
any  case,  one  will  need  an  embedding  sys¬ 
tem,  where  the  whole  object  can  be  run  with 
well  defined  parameter  sets,  and  can  be  ob¬ 
served,  logged,  (statically)  reconfigured,  and 
rerun  again. 

The  NWP  programmer’s  workbench  was  de¬ 
veloped  to  support  these  doings.  The  struc¬ 
ture  of  its  current  Ada  oriented  realization  is 
outlined  in  Fig.  8.  It  currently  supports  the 

•  development  of  process  networks 
and 

•  run  time  analysis  of  process  networks. 


The  NWP  Monitor  uses  SunViews,  the 
graphics  and  windows  interface  of  SUN 
workstations.  This  notwithstanding,  the 
Monitor  can  "look"  beyond  the  limits  of  the 
SUN  subnet  of  a  heterogeneous  network.  It  is 
language-independent  in  that  all  its  analysing 
and  evaluating  capabilities  cover  process  net¬ 
works,  of  which  the  components  are  written 
in  every  supported  language.  The  construc¬ 
tive  means  were  needed  in  an  Ada  centered 
project,  therefore  the  tools  to  handle  commu¬ 
nication  channels  are  Ada  directed,  and  the 
generator  for  test  environments  is  Ada  direct¬ 
ed,  as  well  and  for  the  same  reason. 


Figure  8:  Components  of  the  NWP  workbench 


For  the  first  kind  of  work,  it  offers  tools  to 
handle  communication  channels  in  Ada  and 
generators  for  Ada  test  environments.  The 
second  kind  of  work  benefits  from  NWP 
workbench’s  run  time  support  and  its  Moni¬ 
tor. 

The  Monitor  provides  (see  Fig.  9): 

•  static  analysis  of  the  network  definition, 

•  recognition  of  deadlocks  and  wait  situa¬ 
tions, 

•  run  time  observation  of  process  networks, 

•  recording  and  calculation  of  a  commu¬ 
nication  density, 

•  process  loading  support. 


It  is  in  terms  of  the  above  mentioned  "waiting 
situation"  that  the  enhancement  of  system 
performance  can  be  indicated.  Thus,  in  the 
prototyping  phases  of  developing  a  large  dis¬ 
tributed  system,  the  Monitor  can  supply  rela¬ 
tive  gradients  for  different  configurations  of 
participating  processes  over  a  heterogeneous 
network. 

Classical  methods  of  design  and  analysis  are 
often  strictly  top  down.  On  the  one  hand,  this 
causes  considerable  overhead.  On  the  other 
hand,  it  does  not  lead  itself  very  well  to  sys¬ 
tem  changes.  In  fact:  each  change  is  likely  to 
modify  the  original  top  down  structure,  giv¬ 
ing  rise  to  a  respectable  increase  of  system 
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Figure  9;  Features  of  the  NWP  Monitor 


complexity,  because  maintenance  induces 
degradation  of  structure  [6].  Therefore,  the 
NWP  programmer’s  workbench  supports  an 
evolutionary  approach  and  facilitates  "rapid 
prototyping". 

To  cope  with  complexity,  it  is  recommended 
to  tailor  the  component  processes  of  a  net¬ 
work  to  a  moderate  size  and  such  that  bugs 
can  be  assumed  to  be  absent.  Thus  the  prob¬ 
ability  of  bugs  is  moved  from  the  internal 
structure  to  the  communication  of  processes, 
i.e.  into  the  network.  Here,  because  there  is 
no  common  memory,  and  because  all  com¬ 
munication  is  performed  by  message  passing, 
debugging  is  a  question  of  process  interfaces, 
to  which  the  NWP  workbench  provides  auto¬ 
matic  support.  In  addition,  since  communi¬ 
cation  is  exclusively  done  by  messages,  it  is 
unlikely  that  a  bug  in  one  process  causes  se¬ 
vere  effects  in  another. 

The  NWP  workbench  has  a  toolkit  which 
contains  automatic  generation  of  program 
frames,  and  a  syntax  directed  editor  to  declare 
Ada  types  and  channel  masks.  Thus  we  can 
manipulate  processes  in  order  to  either 
change  an  existing  net,  or  to  expand  it,  or  to 
merge  it  with  another  net.  The  toolkit  con¬ 
tains  also  definition  tools  for  "test  cases"  or 
"test  scenarios". 


By  test  case  we  understand  a  subnet  of  a  proc¬ 
ess  network,  of  which  the  communicative  be¬ 
haviour  is  to  be  tested.  To  do  that,  data  sourc¬ 
es  and  data  sinks  will  be  generated  automati¬ 
cally,  so-called  stubs,  to  snui  the  open 
channels  after  separating  the  subnet  from  its 
surrounding,  cf.  Fig.  10  a&b. 

A  test  scenario  describes  the  circumstances  of 
performing  a  test  case.  The  allocation  of 
processes  to  computers  will  be  defined  here, 
and  the  co-ordination  of  stubs,  computers, 
and  sets  of  test  data  to  be  run,  additionally 
different  operating  modes  for  stubs  can  be  de¬ 
fined  here.  Syntax  directed  editors  for  test 
data  can  be  generated  automatically,  which 
allow  to  input  structured  Ada  types.  Based 
on  the  internal  representation  of  Ada  data 
types,  such  an  editor  produces  an  ASCII  rep¬ 
resentation,  and  thus  assures  portability  of 
data.  A  "normalisator"  will  be  generated  con¬ 
currently  as  a  means  to  produce  an  ASCII  - 
file  of  test  data.  On  the  top  of  this  pan,  a  tool 
to  easily  produce  files  of  test  data  is  provided. 
Fig.  lOc  sketches  the  test  configuration,  i.e. 
the  subnet  and  its  interconnection  to  the  test 
environment,  which  fully  simulates  the  inter¬ 
face  of  the  original  surrounding. 


4,  Modelling  naval  anti-missile  defence 

To  get  an  impression  of  the  ability  of  the 
NWP  workbench,  have  a  look  on  a  Pascal- 
written  subnet  of  a  naval  weapons  guidance 
system  [7].  This  subnet  is  task^  to  detect  po¬ 
tential  mutual  destruction  and  deflection  of 
own  effectors,  which  are  aimed  at  hostile 
anti-ship  missiles.  Different  algorithms  are 
to  be  applied,  whether  destruction  of  an  anti¬ 
missile  missile  by  another  one  or  by  gun  fire 
is  to  be  foreseen,  and  another  kind  of  algo¬ 
rithms,  in  order  to  avoid  one  missile  deviating 
another  one,  in  case  the  second  has  a  pro¬ 
grammed  or  seeking  sensor.  Here,  the  ques¬ 
tion  of  parallel  computation  according  to  dif¬ 
ferent  algorithms,  arises. 


The  Monitor  depicts  the  network  and  the 
clustering  device  can  be  helpful  to  judge  ap- 
propiate  grouping  of  computers  and  their 
connection  to  different  sensors.  The  whole 
model  finds  practical  application  in  the  deci¬ 
sion  process  to  upgrade  resp.  re-design  naval 
weapons  guidance  systems. 

The  first  part  of  the  Monitor’s  screen.  Fig.  1 1 , 
shows  the  project’s  name:  WW,  gives  the 
number  of  dl  possible  network  participants: 
1 1,  while  already  9  of  them  have  introduced 
themselves  to  the  LCS,  or  have  been  men¬ 
tioned  by  some  other  participant.  Ninety 
channels  are  foreseen  within  the  process  net. 
Below  this  window,  the  whole  process  net¬ 
work  is  depicted  as  a  connection  graph,  with 


Project;  ww 

static;  11  Processes. 

dynamic;  9  Processes. 


90  Channels. 


Process  net. 


nowhere 

WW24 


aUSTER  1 
VW23 


nowhere 

WWW 


nowhere 

WW13 


nowhere 

LCS.MONITOR, 


CLUSTER  1 
INIT 


CLUSTER  3 

AAFT 


nowhere 

WW12 


CLUSTER  1: 
KSKS 


CLUSTER  2 
EHEH 


Figure  11:  Monitor’s  state  indicating  window,  and  connection  graph  of  project  WW 
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named  nodes  (processes)  and  edges  to  indi¬ 
cate  the  connections.  Solid  circles  indicate 
that  these  processes  have  already  started  then- 
computing  activity. 

The  top-left  part  of  Fig.  12  shows  a  grouping 
recommendation,  after  the  Monitor  has  eval¬ 
uated  the  communication  intensity  under  the 
network’s  initial  phase:  the  process  WW23, 
which  has  been  initialized  by  INIT,  and  re¬ 
porting  to  the  man-machine-interface  KSKS, 
should  be  run  in  close  connection  to  INIT  and 
KSKS,  on  the  same  machine,  if  possible.  The 
process  EMEM  represents  the  sensors  of  the 
weapons  system,  and  AAFT  reads  an  anti-air¬ 
craft  fire  table.  The  Monitor’s  cluster  analy¬ 
sis  proposes  to  locate  them  on  remote  ma¬ 
chines,  apart  from  the  first  process  cluster. 
The  lower-right  part  of  that  picture  shows  the 
table  of  process  affinities  (i.e.numbers  of 
channels  weighted  with  communications  fre¬ 
quency),  which  the  above  recommendation  is 
based  upon.  This  grouping  is  depicted  with¬ 
in  Fig.  1 1,  and  additionally  that  network  state. 


when  WW23  has  been  told  from  KSKS  to 
communicate  data  to  CANVAS,  in  order  to 
sketch  details  of  a  possible  influence  of  one 
own  missile  upon  the  target-seeking  sensor  of 
another  own  missile.  Heavy  circles  mark  the 
already  active  processes.  CANVAS,  in  it’s 
turn,  using  SUN  View’s  graphical  facilities, 
must  be  resident  on  a  SUN  workstation:  rsp- 
sunl4,  in  this  case,  it  has  not  yet  begun  its  ac¬ 
tivity  and  its  circle  is  still  empty.  Because 
none  of  the  other  WW  -  processes  has  been 
started  by  INIT,  their  border  circles  are  also 
empty,  and  they  reside  "nowhere".  INIT  has 
done  it’s  job  and  has  withdrawn,  thus  it’s  bor¬ 
der  line  is  empty,  too.  The  Monitor  is  not  a 
member  of  the  process  network,  therefore  it  is 
also  flagged  to  reside  nowhere(with  respect 
to  the  project  WW). 

Though  we  did  not  perform  specific  time 
measurements,  we  may  say  that  the  process 
communication  under  LCSes  enables  fire 
control  to  dispose  in  time  over  the  boat’s  re¬ 
sources  and  to  avoid  own  missiles’  "fratri¬ 
cide". 


Figure  12:  Monitor’s  grouping  recommendation  based  on  process  communication  history 
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Appendix: 

Subsequently,  the  listings  of  our  RPC-simulation  example  are  given.  Because  this  example  is 
coded  in  Ada,  first  the  language  interface  for  Ada  is  partly  listed,  as  an  example  high  level  lan¬ 
guage  interface. 


LCS_INTERFACE  l-Mar-1991  19:07:34  VAX  Ada  VI. 5-44 

1  —  LCS_INTERFACE  for  Ada,  12.12.88  VMS  type 

2  - - 

3  paek«g«  LCS_INTERFACE  Is 

4  typs  CHANNEI,_ID  is  privsts; 

5  typs  CHANMEL_SET  is  privst*; 

6  INVAI,ID_MEMBER  :  constant  CHANNEL_ID; 

7  LCS_SySTEM_ERROR, 

8  LCS_USER_ERROR, 

9  LCS_SI2E_ERROR, 

10  NOT_IMPLEMENTED, 

11  CHANMEL_CLOSED  :  sxcaptlon; 

12  typa  COMMUNICATION_KIND  is 

13  (  give_to,  give_wait_to,  give,  give_wait, 

14  write_to,  write, 

15  take_from,  take,  read_from,  read  ) ; 


19 

procedure  LOGON_PROCESS  (  ! 

PROCESS : STRING  )  ; 

20 

procedure  LOGOFF_PROCESS  ( 

PROCESS : STRING  ) ; 

21 

procedure  SELECt'channel ( 

CHOICE 

:  in  CHANNEL  SET; 

22 

WAITING  SET:  out  CHANNEL  SET 

23 

COUNT 

:  out  INTEGER 

) ; 

24 

procedure  S  E  LECT_CHANNEI,  ( 

CHANNEL 

:  in  CHANNEL  ID; 

25 

WAITING  SET:  out  CHANNEL  SET 

f 

26 

COUNT 

:  out  INTEGER 

)  ! 

32  generic  type  me33age_type  is 

33  package  INTERFACE  is 

private; 

34 

procedure  GIVE(  CHANNEL  : 

in  CHANNEL_ 

ID; 

35 

MESSAGE  : 

in  MESSAGE_ 

TYPE) ; 

51 

procedure  TAKE(  CHANNEL  : 

in  CHANNEL_ 

ID; 

52 

MESSAGE  : 

out  MESSAGE  TYPE; 

53 

SENDER  ■: 

out  STRING 

)  ; 

63 

procedure  CREATE_CHANNEL 

64 

(  MODE  : 

in  COMMUNICATION_ 

KIND 

bo 

SENDER  : 

in  STRING 

6t. 

RECEIVER  : 

in  STRING 

67 

CHANNEL_NAME  : 

in  STRING; 

68 

CAPACITY  : 

in  INTE>jER:=«1; 

69 

CHANNEL  : 

out  CHANNEL  ID 

) ; 

70 

procedure  CLOSE_CHANNEL ( 

CHANNEL  •:  in  CHANNEL_ID  )  ; 

71  end  INTERFACE; 

72  - - - 

73  —  Functiona  to  handle  channel  sets 


90  private 

96  end  LCS_INTERFACE; 

i 
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SERVER  l-Mar-1991  18:21:03  VAX  Ada  VI. 5-44 

1  with  TEXT_IO, INTEGER_TEXT_IO,  LCS_INTERFACE; 

2  use  TEXT_IO, INTEGER_TEXT_IO,  LCS_INTERFACE; 

5  procedure  SERVER  is 

6  SENDERNAME  :  STRING (1 .. 32) ; 

7  NUMBER  :  INTEGER; 

8  TO_SERVER  :  CHANNEL_ID; 

9  FROM_SERVER  :  CHANNEL_ID; 

10  package  S  is  new  INTERFACE (INTEGER) ; 

11 

12  begin 

13  —  Start  communication  with  local  LCS: 

14  LOGON_PROCESS (  "SERVER"  ); 

15  —  Define  a  channel  from  client  processes  to  this  one, 

16  —  channel's  name  is  to  be  "TO_SERVER", 

17  —  its  handle  is  TO_SERVER,  here: 

18  S . CREATE_CHANNfiL (  MODE  =>  take, 

19  CHANNEI,_NAME  =>  "TO_SERVER", 

20  CHANNEL  ”>  TO_SERVER  ); 

21  —  Define  a  channel  to  client  processes, 

22  —  of  buffer-synchronous  mode  and 

23  —  channel's  name  is  to  be  "FROM_SERVBR", 

24  —  its  handle  is  FROM_SERVER,  here: 

25  S . CREATE_CHANNEL (  MODE  »>  give_wait, 

26  ~  CHANNEL_NAME  ->  "FROM_SEPVER", 

27  CHANNEL  ->  FROM_SERVER  )  ; 

28  NEW_LINE; 

29  —  Listen: 

30  loop 

31  --  accept  a  message  from  a  client 

32  S.TAKEi  TO_SERVER,  NUMBER,  SENDERNAME  ); 

33  —  Print  the  client's  name  and  the  message: 

34  PUT(  SENDERNAME  );  PUT(  "  :  "  );  PUT (  NUMBER, 5  ) ; 

35  NEW_LINE; 

36  —  Respond  by  sending  back  the  message  to  it's  sender: 

37  S.GlVE(  FROM_SERVER,  NUMBER  ); 

38  —  Here  an  exit  should  take  place  if  a  condition  holds 

39  end  loop; 

40  —  Good-bye!  to  LCS 

41  LOGOFF_PROCESS (  "SERVER"  ); 

42  end  SERVER; 


CLIENT  l-Mar-1991  18:20:29 


VAX  Ada  VI. 5-44 


1  with  TEXT_IO,  INTEGER_TEXT_IO,  LCS_INTERFACE; 

2  use  TEXT_IO, INTEGER_TEXT_IO,  LCS_INTERFACE; 


5  procedure  CLIENT  is 

6  SENDERNAME  :  STRING (1. .32)  ; 

7  NCLIENT  :  INTEGER; 

8  LC,  NUMBER,  ERGEBNIS  :  INTEGER  :=  1; 

9  TO_SERVER  :  CHANNEL_ID; 

10  FROM_SERVER  :  CHANNEL_ID; 

11  package  C  is  new  INTERFACE (INTEGER) ■ 

12 


13  begin 

14  —  Individualization:  ask  user  for  a  (unique)  number 

15  PUT(  "CLIENT  X:  GIVE  ME  A  NUMBER  X:"  );  NEW_LINE; 

16  GET(  NCLIENT  ); 

17  —  Start  communication  with  local  LCS: 

18  LOGON_PROCESS (  "CLIENT"iinteger' IMAGE (NCLIENT)  ) ; 

19  —  Define  a  channel  to  server  process, 

20  —  of  synchronous  mode, 

21  —  with  this  process  as  sender, 

22  —  channel's  name  is  to  be  "TO_SERVER", 

23  —  its  handle  is  TO_SERVER,  here: 

24  C . CREATE_CHANNEL (  MODE  ->  giv6_wait, 

25  "  SENDER  =>  "CLlENT"fiinteget' IMAGE (NCLIENT) , 

26  CHANNEL_NAME  ->  "TO_SERVER", 

27  CHANEL  ->  TO_SERVER  )  ; 

28  —  Define  a  channel  from  server  process  to  this  one, 

29  --  with  this  process  as  receiver, 

30  —  channel's  name  is  to  be  "FROM_SERVER", 

31  —  its  handle  is  FROM_SERVER: 

32  C.CREATE_CHANNEL(  MODE  »>  take, 

33  ~  RECEIVER  ->  "CLIENT"Sinteger' IMAGE (NCLIENT), 

34  CHANNEL_NAME  ->  "FROM_SERVER", 

35  CHANNEL  ->  FROM_SERVER  ) ; 

36  —  Activity:  ask  user,  how  many  actions  consisting  in 

37  —  sending  the  action  number  should  be  undertaken? 

38  P0T(  "GIVE  LOOPCOUNT:”  );  NEW_LINE;  GET (  LC  ); 

39  for  I  in  1..LC  loop  —  set  action  number 

40  C.GIVE(  TO_SERVER,  I  );  —  Send  number  to  server 

41  —  Accept  answer  from  server  and  print  it: 

42  C.TAKE(  FROM_SERVER,  ERGEBNIS,  SENDERNAME  ); 

43  P0T(  ERGEBNIS, 5  );  P0T(  "  from  "  ) ;  PUT(  SENDERNAME  ) ; 

44  —  Flag  an  error,  if  server  didn't  answer  properly: 

45  if  I  /-  ERGEBNIS  then  PUT(  "ERROR"  ) ;  end  if; 

46  1  EW_LINE; 

47  •ui'.  loop; 

48  -  !'-v.-ng  sent  LC  action  numbers,  "Good-bye!"  to  LCS: 

49  ;  jOFF_PROCESS (  "CLIENT"Sinteger' IMAGE (NCLIENT)  ); 

50  ^ception  —  In  case  of  an  error,  print  its  class  and 

51  —  give  farewell  to  LCS  at  any  case: 

52  when  LCS_USER_ERROR  =>  PUT(  "USER_ERROR"  ); 

53  LOGOFF_PROCESS ("CLIENT"S integer'  IMAGE (NCLIENT) ) ; 

54  when  OTHERS  =>  PUT(  "OTHER  EXCEPTION"  ); 

55  LOGOFF_PROCESS (  "CLIENT"Sinteger' IMAGE (NCLIENT)  ); 

56  end  CLIENT; 
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1  Abstract 

A  need  has  been  identified  for  a 
generalised  approach  to  the 
specification,  design  and  development 
of  real  time  embedded  systems.  There 
are  many  tools  that  cover  different 
parts  of  the  life  cycle.  Some  of  these 
are  integrated  to  various  degrees,  but 
for  real  time  systems  it  is  probably 
true  to  say  that  there  is  not  a  set  of 
integrated  tools  which  covers  all 
phases  of  the  life  cycle.  This  paper 
describes  the  way  that  the  Data 
Oriented  Requirements  Implementation 
Scheme  (DORIS)  attempts  to  remedy  this 
situation.  DORIS  is  an  applied 
research  project  at  British  Aerospace 
(Dynamics)  Ltd,  United  Kingdom. 


2  Introduction 

DORIS  is  a  set  of  integrated  methods 
and  associated  tools  for  the 
development  of  real  time,  embedded, 
multiprocessor  systems.  It  covers  the 
whole  of  the  development  life  cycle 
from  the  requirements  analysis  through 
to  implementation  in  software  and 
hardware.  The  main  aim  of  DORIS  is  to 
support  the  development  of  safe  and 
reliable  systems.  Particular  emphasis 
has  been  placed  on  direct  support  for 
the  development  of  multiprocessor 
systems,  reducing  timing 
Indeterminancies  and  supporting  the 
traceability  of  requirements. 

Figure  1  shows  the  fundamental  steps 
that  have  to  be  made  when  developing  a 
system.  DORIS  uses  two  existing 
nethods  based  on  the  idea  of  dataflow: 
"he  Controlled  Requirements  Expression 


(CORE)  [1]  is  used  for  the  definition 
phase,  and  a  method  known  as  Modular 
Approach  to  Software  Construction, 
Operation  and  Test  (MASCOT)  [3]  is  used 
for  the  design  phase.  These  methods 
have  to  be  extended  and  adapted  so  that 
they  can  be  integrated  into  the  DORIS 
scheme 

Implementation  is  achieved  using  a  new 
architecture  known  as  the  Data 
Interaction  Architecture  (DIA)  [6]. 

The  DIA  is  based  around  shared  memory 
and  offers  fully  controlled 
asynchronous  communication  (in  addition 
to  the  more  conventional  synchronous 
communication).  It  uses  two  specially 
designed  chips  to  support 
multiprocessor  applications. 

Many  existing  proprietary  tool  sets  and 
methods  tie  the  user  into  a  specific 
language,  host  or  target.  British 
Aerospace  has  such  a  large  variety  of 
projects  that  standardization  on  any  of 
these  is  Impractical.  One  of  the  main 
aims  of  the  DORIS  approach  is  that  it 
will  be  language,  host  and  processor 
independent.  This  will  lead  to  a 
standardization  across  products,  which 
in  turn  will  lead  to  Improved 
productivity . 


3  Requirements  Analysis 

CORE  is  both  a  method  and  a  tool 
designed  specifically  for  the 
requirements  phase  of  the  development 
life  cycle.  The  metnod  has  been 
developed  by  British  Aerospace 
(Military  Aircraft)  Ltd  and  System 
Designers  Ltd  in  the  United  Kingdom. 
CORE  establishes  the  actual  problem  to 
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be  solved,  and  reduces  ambiguities  and 
inconsistencies  in  the  customer’s 
requirements.  It  also  highlights  the 
effects  produced  by  changing  the  system 
specifications  and  formalises  these 
system  specifications  so  that  they  are 
understood  and  agreed  by  all  involved 
in  the  p.'oject.  [2] 

CORE  consists  of  a  set  of  defined  steps 
for  the  deveivftcnt  of  systems 
requirements  models.  It  encourages 
structure  and  therefore  modularity,  and 
identifies  the  data  flow  between  the 
elements. 

The  main  concept  of  CORE  is  that  of 
’viewpoints’.  These  describe  the 
nature  and  content  of  the  problem  as 
seen  from  particular  points  of  view. 
Each  viewpoint  looks  at  the  problem  in 
terms  of  the  information  acquired,  the 
processing  of  this  information  and  the 
generation  of  output  results. 

CORE  avoids  using  complex  mathematical 
notation,  and  yet  still  achieves  the 
necessary  degree  of  formality  required 
for  requirements  analysis.  This  makes 
CORE  more  acceptable  to  the  engineering 
community. 

Once  the  behaviour  of  the  system  is 
described,  this  information  can  be  used 
as  the  requirements  document  for  the 
design  teams. 


4  Design 

Figure  2  shows  the  structure  of  the 
design  tool  set.  Three  languages  have 
been  provided  for  the  design  phase  of 
DORIS.  These  are: 

-  DORIS  Design  Language  (DDL) 
Specifies  the  software  design  of 
the  system  (based  on  MASCOT). 

-  Hardware  Description  Language 
(HDD 

Describes  the  configuration  of 
the  processors,  the  memories  and 
the  interfaces  between  the 
memories . 


-  Mapping  Description  Language 
(MDL) 

Maps  the  designer’s  MASCOT 
activities  into  specific 
processors. 

The  DDL  is  an  adapted  form  of  MASCOT 
[3,  4,  5].  MASCOT  was  developed  at  the 
Royal  Signals  and  Radar  Establishment 
in  the  United  Kingdom  and  has  been 
adopted  by  the  United  Kingdom  Ministry 
of  Defence  as  a  standard  approach  for 
the  development  of  embedded  systems. 
MASCOT  is  a  network  approach  to 
software  design  suitable  for  multi¬ 
processor  systems.  It  gives 
Independence  from  specific  processors 
and  provides  a  framework  for  specifying 
interconnections  and  Interfaces  between 
different  software  (and  indeed 
hardware)  components  in  the  system.  It 
has  both  a  graphical  and  a  textual 
form,  each  of  which  can  be  derived  from 
the  other. 

In  MASCOT,  activities  are  sequential 
processes,  concerned  primarily  with 
performing  a  single  function.  Each 
activity  is  conceptually  independent, 
i.e.  it  runs  concurrently  with  all 
other  activities.  Activities 
communicate  with  each  other  through 
shared  data  areas,  known  as 
Intercommunication  Data  Areas  (IDAs), 

Certain  extensions  have  been  made  to 
MASCOT  so  that  communication  between 
the  MASCOT  elements  in  independent  of 
both  the  hardware  configuration  and  the 
type  of  the  data  being  communicated. 
This  has  been  achieved  by  adding  the 
idea  of  a  Route  to  MASCOT.  A  Route  is 
a  specialised  form  of  an 
Intercommunication  Data  Area,  with  one 
input  and  one  output.  It  enables 
information  to  be  passed  from  one 
activity  to  another,  unchanged.  It  can 
be  used  to  provide  either  asynchronov  s 
or  synchronous  communication  between 
the  two  processes. 

To  allow  this  to  be  implemented,  the 
concept  of  type-independence  has  been 
added  to  MASCOT.  This  allows  the  data 
type  to  be  specified  at  instantiation. 
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In  MASCOT,  a  template  a  standard 
pattern  for  the  design  of  a  component 
in  the  system.-  When  the  designer  wants 
to  use  a  component  of  that  design,  he 
creates  an  instance  of  the  template. 

As  part  of  the  DORIS  system,  it  is 
intended  that  standard  templates  will 
be  provided  to  help  communication 
between  activities  in  the  system.. 

These  templates  will  provide  four 
methods  of  communication  from  a  sending 
process  (the  writer)  to  a  receiving 
process  (the  reader).  These  are: 

Fully  Asynchronous 
This  method  of  communication 
allows  the  reader  and  the  writer 
to  operate  independently  of  each 
other. 

Conditionally  Asynchronous 
This  form  of  communication  is  a 
limited  form  of  the  fully 
asynchronous  mechanism.  It  is 
guaranteed  to  work  satisfactorily 
if  the  interval  between 
successive  writes  is  always 
greater  than  the  duration  of  any 
read. 

-  Loosely  Synchronous 

This  does  not  require  that  the 
two  processes  are  at  the  same 
place  at  the  same  time  to 
exchange  information.  It  does 
however,  exercise  some  constraint 
over  the  relative  operation  of 
the  two  processes  by  limiting  the 
extent  to  which  the  production  of 
information  can  get  ahead  of  its 
consumption.  In  effect,  it  is  a 
bounded  buffer. 

Fully  Synchronous 
This  is  a  rendezvous,  which  locks 
together  the  operation  of  the  two 
processes  at  or  during  the 
exchange  of  information.  There 
must  be  a  point  in  time  at  which 
the  two  processes  meet.  Data  can 
then  be  passed  between  the  two 
and  they  can  then  carry  on 
independently . 

In  addition,  three  distribution 
possibilities  will  be  provided  for  a 


Route: 

Private 

The  activities  using  the  route 
are  both  in  the  same  processor 

-  Shared 

The  activities  using  the  Route 
are  in  different  processors, 
connected  by  shared  memory. 

-  Remote 

The  activities  using  the  Route 
are  in  different  processors,  not 
connected  by  shared  memory. 

The  software  designer  will  be  able  to 
define  a  Route  between  two  activities, 
regardless  of  their  mapping  into 
hardware.  At  build  time,  the  builder 
will  determine  the  relative 
distribution  of  the  activities,  and 
will  substitute  a  Route  with  the 
necessary  distribution.  This  allows 
the  software  to  be  designed  without 
needing  to  know  how  the  activities  are 
mapped  into  the  processors..  One 
benefit  of  this  is  that  the  software 
can  be  tested  in  the  host,  using  a 
private  distribution,  and  then  the 
activities  can  be  mapped  into  different 
processors,  without  requiring  a 
corresponding  software  design  change. 

The  design  tools  provided  with  DORIS 
will  allow  the  software  design  and  the 
hardware  configuration  to  be  easily 
changed.-  It  is  intended  that  the  basic 
toolset  will  contain: 

-  Graphical  Design  Tools 

Timing  Analysis  Tools  (SPIRITS) 
Textual  Analysis  and  Checking 
Tools  vDAN,  HAN,  MAN) 

Build/link  tools  (Builder) 
Loader/Monitor  (DEMON) 

-  Run-time  development  tools 

It  is  Intended  that  the  DDL,  HDL  and 
MDL  will  have  graphical  front  ends  to 
simplify  the  network  design.  There  is 
also  a  textual  form  of  all  three 
languages.  One  possible  front  end  to 
DDL  is  MADGE  (MASCOT  Design  GEnerator). 
This  has  been  developed  by  British 
Aerospace  (Dynamics)  Ltd  and  supports  a 


15-4 


graphical  form  of  MASCOT. 

The  problems  of  timing  analysis  are 
being  addressed  by  a  Department  of 
Trade  and  Industry  sponsored  initiative 
called  SPIRITS  (Supporting  Predictable 
Implementation  of  Requirements  In 
Timing  and  Safety).  This  is 
investigating  the  need  to  develop  hard 
real  time  systems  whose  timing  and 
safety  properties  are  known  and  can  be 
shown  to  satisfy  the  existing 
requirements . 

Figure  2  shows  the  relationship  of  the 
textual  analysis  and  checking  tools. 

The  DDL  Analyser  (DAN)  checks  the  DDL 
text  (either  generated  by  the  user  or 
by  MADGE  or  similar  tool).  If  the 
syntax  is  correct,  it  places  the 
network  connectivity  information 
contained  in  the  text  (how  the 
components  in  the  system  are  connected) 
into  the  template  database,  and  creates 
source  files  in  the  selected  target 
language  for  syntax  checking  using 
commercially  available  compilers.  This 
use  of  propriety  compilers  aids  the 
language  independence  of  DORIS. 

The  Mapping  Description  Language 
Analyser  (MAN)  and  Hardware  Description 
Language  Analyser  (HAN)  both  store  the 
information  contained  in  the  MDL  and 
the  HDL  into  appropriate  databases  for 
use  by  the  builder. 

The  Builder  checks  that  all  the 
activities  specified  in  the  DDL  are 
mapped  to  processors  specified  in  the 
HDL.  It  also  checks  that  for  all  IDAs, 
an  IDA  template  suitable  for  the 
appropriate  mapping  is  available  in  the 
database.  It  generates  instances  of 
the  templates  with  the  correct 
connection  between  activities  and  IDAs. 
For  each  processor  in  the  system,  the 
builder  generates  a  list  of  activities 
resident  in  the  processor,  and  presents 
the  instances  of  activities  and  IDAs  to 
the  compiler  and  linker. 

The  loader /monitor  (DEMON)  provides 
facilities  to  allow  multiprocessor 
loading  and  host/multitarget 
communications . 


DORIS  run  time  development  tools  will 
be  provided  that  provide: 

Detection  and  reporting  of  run 
time  errors 

-  Breakpoint  handling 

-  Memory  examination 

-  User  Defined  Debug  Messages 
(MASCOT  record  primitive) 

-  MASCOT  primitive  monitoring 

-  MASCOT  execution  control 

-  Timing  data  collection 


5  Implementation  -  The  Data 
Interaction  Architecture 

The  aim  of  the  Data  Interaction 
Architecture  (DIA)  is  tu  provide  a 
mechanism  to  support  multi-tasking  and 
multi-processing  systems.  It  uses 
simple  hardware  elements,  giving 
predictable  behaviour  for  high 
integrity  systems.  The  DIA  provides 
direct  hardware  support  for  MASCOT 
designs . 

Figure  3  shows  the  basic  configuration 
of  an  element  in  the  DIA.  Ideally  the 
Central  Processing  Unit  (CPU)  is  a 
relatively  simple  form  of  Reduced 
Instruction  Set  Computer  (RISC)  in 
which  no  use  is  made  of  features  that 
Introduce  non  deterministic  timing 
effects  including  interrupts  and 
caching.  More  complex  computers  can  be 
used,  but  this  will  make  it  more 
difficult  to  analyse  run  time 
properties.  [6) 

The  CPU  has  a  private  bus  that  allows 
it  to  be  connected  to: 

-  private  memory  (containing 
activities  and  private  IDAs) 

-  Asynchronous  devices  (polled 
peripheral  devices) 

Synchronous  devices  (peripheral 
device  generating  a  stimulus) 

-  Asynchrorous  Dual  Port  Memory 
(ADPM,  containing 
Intercommunication  Data  Areas 
shared  with  activities  in  an 
adjacent  processor) 

Two  sorts  of  specially  developed 
VLSI  device,  the  Kernel 
Integrated  Circuit  (KERIC)  and 
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the  Communication  Integrated 
Circuit  (COMIC).- 

The  Kernel  Integrated  Circuit  supports 
low  level  scheduling,  providing  the 
multi-tasking  facilities  needed  when 
many  activities  are  mapped  onto  a 
single  processor,  as  well  as  handling 
external  stimuli  (from  timers  etc.) 
without  using  interrupts.  It  selects 
which  activity  is  to  be  scheduled  by 
using  built  in  priority  and  polling 
rules.  It  supports  cooperative 
scheduling  in  preference  to  pre-emptive 
(or  interrupt  driven)  scheduling.  Use 
of  the  Kernel  Integrated  Circuit  avoids 
the  timing  overheads  normally  found  in 
software  based  executives., 

A  processor  communicates  with  an 
adjacent  processor  via  shared  memory. 
The  aim  of  this  is  to  remove  the  need 
for  buses,  thus  eliminating  the  risk  of 
a  "single  point  of  failure".  It  is 
intended  that  the  shared  memory  used  in 
DORIS  should  be  Asynchronous  Dual  Port 
Memory  (ADPM) ,  although  other  devices 
can  be  used.  The  Communication 
Integrated  Circuit  is  used  to  control 
the  access  to  the  shared  memory, 
allowing  activities  in  adjacent 
processors  to  pass  data  from  one  to 
another.  An  Asynchronous  Dual  Port 
Memory  without  arbitration  bas 
currently  been  selected,  wi.j.ch  avoids 
any  timing  interference.-  Four 
different  forms  of  communication  are 
supported:  fully  asynchronous; 
conditionally  asynchronous;  loosely 
synchronous;  fully  synchronous. 

A  facility  is  provided  that  allows  the 
COMIC  to  signal  to  the  KERIC  in  the 
destination  processor  that  data  has 
arrived  for  it,  and  that  the 
appropriate  activity  can  be 
rescheduled . 


6  Conclusion 

DORIS  aims  to  provide  support  for  the 
development  of  safe  and  reliable 
systems.  It  does  this  by: 

-  Reducing  timing  indeterminancies 


Co-operative  scheduling  will  be 
used  instead  of  interrupts. 

No  inter-processor  buses  will  be 
used.; 

No  caching  will  be  used. 
Asynchronous  Communication  will 
be  used. 


Multiprocessor  Support 

Design,  Mapping  and  Hardware 
Description  languages  will  be 
provided. 

The  substitution  of  templates  in 
the  builder  allows  the  software 
design  to  be  mapped  as 
appropriate  to  the  hardware 
available.; 


Traceability  of  Requirements 

The  use  of  CORE  and  MASCOT  will 
provide  the  means  of  tracing  the 
requirements  through  to 
implementation  .- 
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Summary 

This  paper  discusses  a  software  design  method 
for  real-time  applications  written  in  Ada.  It  proves 
that  even  time  critical  systems  can  be  implemented  in 
pure  Ada. 

The  design  method  is  based  on  the  Ada  tasking 
model  in  conjunction  with  object-oriented  design 
(OOD)  principles.  Special  purpose  graphs,  derived 
from  Yourdon/De  Marco  data  flow  diagrams 
(DFD’s),  illustrate  the  method,  while  Ada  program 
design  language  (PDL),  as  a  counterpart  to  the 
graphs,  serves  as  a  basis  for  the  software  imple¬ 
mentation. 

No  global  cyclical  executive  is  used  to  schedule 
the  concurrent  threads  of  execution.  Instead,  a 
rendezvous-based  interaction  of  Ada  tasks  provides 
the  scheduling.  This  is  automatically  generated  from 
an  Ada  compiler. 

This  software  design  technique  is  illustrated  by 
the  development  of  the  operational  flight  software  lor 
an  experimental  helicopter. 


1.  Introduction 

In  the  past,  real-time  systems  were  implemented 
using  a  dedicated  operating  system  on  the  target 
computer  or  using  a  higher  level  pre^amming 
language  with  real-time  extensions.  Mncc  the  intro¬ 
duction  of  Ada,  a  widely  accepted  programming 
language  is  available  which  incorporates  real-time 
features  such  as  tasking  or  interrupt  handling  in  the 
language  itself. 

Moreover,  complex  real-time  software  deve¬ 
lopment  demands  a  language  with  design  features, 
modularity  concepts  and  precautions  for  team-effort 
implementation.  Therefore,  Ada  was  equipped  with 
such  features  as  packages,  generics  and  separate 
compilation. 

These  two  aspects  prove  Ada  to  be  a  very  good 
tool,  both  for  the  design  and  for  the  implementation 
of  complex  real-time  systems. 


In  this  paper  a  comprehensive  design  metho¬ 
dology,  whicn  strongly  utilize  Ada’s  design  and  real¬ 
time  features,  is  presented.  The  methodology  focuses 
on  large  real-time  systems,  giving  a  practical,  step-by- 
step  design  approach,  which  is  documented  in  several 
graphical  illustrations  and  can  be  canonically  trans¬ 
formed  to  Ada  program  design  language. 

As  an  example,  the  design  methodology  is 
applied  to  an  experimental  helicopter  project  which 
is  currently  under  development  at  ESG. 

In  the  following  chapter,  we  briefly  describe  the 
example  project.  Chapter  3  explains  the  methodology 
and  applies  it  to  the  project.  Cnapter  4  continues  the 
description  of  the  design,  concentrating  on  refinement 
steps  under  utilization  of  OOD  techniques.  Chapter  5 
is  dedicated  to  real-time  scheduling  and  software 
performance  issues,  discussing  the  question  of 
whether  the  scheduling  based  on  the  Ada  tasking 
model  is  applicable  in  time  critical  systems.  The  final 
chapter  summarizes  the  experiences  with  the  design 
method. 


2.  A  typical  real-time  project 

At  ESG,  a  project  is  currently  under  deve¬ 
lopment  which  equips  a  helicopter  with  experimental 
avionic  instrumentation.  The  helicopter  will  facilitate 
the  analyses  of  advanced  equipment  components  and 
of  the  man-machine  interface  aspects  of  a  modern 
cockpit  in  the  course  of  flight  trials.  Modern 
computer-controlled  displays  and  sensors  are  at  the 
pilots  disposal  to  gain  flight  experience  in  a  realistic 
environment.  The  results  of  these  flight  experiments 
are  a  valuable  input  for  and  can  prove  the  feasibility  of 
later  helicopter  products  like  the  Gerraan/French 
Tiger"  anti-tank  helicopter. 

Due  to  the  experimental  character  of  the  project, 
the  .system  and  software  design  should  be  flexible  and 
easy  to  alter  or  extend.  Clearness,  ease  of  change  and 
reusability  are  important  demands  on  the  software 
development  effort.  All  software  for  the  avionic 
system  is  implemented  in  Ada. 

Figure  1  shows  the  system  architecture  of  this 
example  project: 


Figure  1:  System  architecture  of  the  experimental  helicopter 


The  avionic  computer  is  a  multinroccssor  system, 
based  on  Motorola  6^30  boards,  witn  an  integrated 
graphic  symbol  generator.  All  display  and  control 
units,  ana  the  sensors,  are  electrically  connected  to 
special  input/output  boards  of  the  avionic  computer. 

The  pilot  controls  the  avionic  instrumentation 
with  a  menu  ^ded  terminal  and  with  the  help  of  a 
topographical  map  device. 

All  important  flight  information  (flight  routes, 
danger  areas,  helicopter  attitude  and  velocities)  is 
displayed  and  continually  updated  on  special  multi¬ 
color  graphic  devices. 

In  addition  to  the  usual  inertial  navigation 
system,  a  very  precise  satellite  controlled  navigation 
system  (GPS)  is  utilized. 

Last  but  not  least,  the  pilot  wears  a  helmet 
mounted  sight/display  device;  digital  information  is 
mbied  with  the  video  image  of  the  forward  looking 
infrared  camera  and  can  be  projected  on  the  screen 
of  the  helmet.  The  camera  is  controlled  through 
movements  of  the  pilot’s  head. 


3.  The  Ada  software  design  method 

The  software  design  for  the  helicopter  project  is 
derived  from  a  methodology  developed  oy  Nielsen 
and  K.  Shumate  at  Hughes  Aircraft  Company  (see 
[1|).  It  is  based  on  the  Ada  tasking  model  in  con¬ 
junction  with  object  oriented  design  (OOD)  features. 
Graphics  illustrate  the  global  design  steps  and  can  be 
canonically  transfered  into  Ada  program  design 


language  (PDL).  The  global  design  is  process  orien¬ 
ted,  leading  to  the  identification  of  all  concurrent 
processes  and  their  interactions.  In  Ada,  these  are 
described  as  tasks  and  rendezvous.  In  a  refmement 
step  of  the  design,  Ada  PDL  is  further  developed  to 
outline  the  sin^e  threads  of  execution  of  each  task 
using  OOD  methods. 

In  the  following,  the  methodology  will  be 
explained  step-by-step  and  illustrated  through 
examples  from  tne  experimental  helicopter  project. 

At  first,  one  tries  to  identify  the  main  software 
functions  and  their  real-time  executions,  i.e.  whether 
they  perform^  event-driven  or  execute  periodically.  A 
textual  description  of  the  requirements  for  the  project 
will  normally  oe  the  basis  for  this  step.  As  discussed  in 
more  detail  in  chapter  5,  no  global  cyclical  scheduler 
will  be  used  in  this  kind  of  design,  but  all  the  real-time 
issues  will  be  handled  with  the  Ada  tasking  model. 
Therefore,  it  is  important  to  fit  the  main  software 
functions  in  concurrent  processes  which  will  be 
described  as  Ada  tasks.  The  real-time  execution  of 
these  tasks  is  provided  implicitly  by  the  Ada  compiler, 
their  interaction  is  controlled  by  Ada  rendezvous. 

But  bow  does  one  find  these  tasks?  They  should 
be  combinations  of  cohesive  software  functions.  Some 
will  execute  priodically,  others  event-driven.  In  the 
latter  case,  they  may  be  triggered  by  interrupt.  The 
design  methodology  defines  a  comprehensive 
procedure  for  the  identification  of  these  tasks: 

The  so-called  "edges-in  approach’  assigns  a 
concurrent  process  to  each  of  the  interface  handlers 
which  connect  the  external  hardware  devices  with  the 
main  avionic  application.  Here,  the  main  part  is  not 
yet  specified,  only  its  data  flows  to  the  outside  world. 
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This  first  ste^s  illustrated  in  the  top-level  data  flow 
diagram  (DTO).  See  figure  2  for  a  mapping  of  the 
helicopter  system  architecture  onto  a  top  level 
software  DFD.  The  interaction  with  the  hardware 
devices  (navigation  systems,  pilot  controls, is 
controlled  concurrent  handler  processes.  In  the 
case  of  functional  cohesion,  some  of  these  handler 
processes  may  be  combined  to  one  process  in  order  to 
reduce  the  number  of  different  tasks  in  the  system. 

In  the  next  steps,  the  main  avionic  application 
(middle  part)  is  decor'oosed  using  a  hierarchy  of 
DFD’s.  The  tool  for  this  step  is  the  good  old 
Yourdon/De  Marco  DFD,  applied  not  for  functional 
analysis  of  the  project  but  for  software  design.  Hence, 
one  cannot  just  map  the  transforms  and  data  flows  of 
the  requirement  description  onto  software  modules.  It 
is  necessary  to  set  up  a  new,  shallow  leveled  DFD 
structure  with  the  aim  to  combine  transforms  to 
concurrent  software  processes.  During  this  procedure, 
one  has  to  consider  tne  resulting  interactions  of  the 
so-formed  concurrent  processes.  They  run  in  parallel 
and  interact  with  each  other.  Therefore,  one  carefully 
has  to  avoid  mutual  waiting  situations,  i.e.  dead-locks. 
Sometimes  intermediary  processes  (buffer^  queues, 
...)  have  to  be  introduced  to  decouple  applications. 

For  the  process  identification,  i.e.  the  combination  of 
certain  DFD  functions,  functional  cohesion,  as  well  as 
temporal  dependencies,  are  to  be  considered.  Typical 
reusable  objects,  such  as  monitors  for  a  critical  data 
region,  servers  or  periodic  modules,  are  examples  of 
such  processes. 

Figures  3  and  4  illustrate  the  software  DFD 
structure  and  process  identification  in  the  experi¬ 
mental  helicopter  project:  Rgure  3  shows  that  the 
AVT  middle  part  consists  of  four  major  software 
functions  (terminal,  flight  and  graphics  management. 


as  well  as  moding  control).  For  performing  process 
identification,  this  level  of  DFD  hierarchy  is  not  suffi¬ 
cient.  As  an  example,  in  figure  4,  the  flight  manage¬ 
ment  is  further  refmed  to  a  level  where  one  can  iden¬ 
tify  the  concurrent  processes:  helicopter  control,  flight 
control,  navigation  and  obstacle  warning  should  run 
concurrently.  The  navigation  process  is  a  combination 
of  the  software  functions  navigational  computation 
and  height  warning,  and  the  data  storage  for  NAV- 
data  and  height  limits.  Its  real-time  performance  is 
event  driven.  Whenever  new  navigational  data  arrives 
in  the  system  (through  certain  handlers,  see  figure  2), 
the  process  becomes  active.  Only  in  the  case  of  new 
heim  data  the  height  warning  function  will  be 
performed.  Hence,  the  height  warning  software 
function  is  integrated  into  the  navigation  process.  The 
flight  control  process  monitors  the  routes,  guaran¬ 
teeing  mutually  exclusive  access  to  these  flight  routes. 
The  obstacle  warning  is  a  typical  periodic  task.  Every 
.second,  possible  obstacles  along  tne  flight  track  are 
checked. 

Now,  all  processes  are  determined  and  can  be 
graphically  illustrated  in  a  single-level  process 
structure  chart.  At  this  stage,  a  textual  representation 
of  the  software  can  begin.  Because  of  the  excellent 
design  features  of  Ada,  this  will  result  in  readily 
compilable  Ada  PDL  which  corresponds  directly  to 
the  ^aphical  representation  and  is  easily  readable. 
The  concurrent  processes  are  described  as  Ada  tasks. 
A  hierarchical  dependency  of  tasks  must  be  avoided. 
All  concurrency  must  be  visible  at  the  top  level.  In 
order  to  support  separate  compilation  and  readability, 
the  tasks  will  be  embedded  in  Ada  packages,  strictly 
separating  the  specification  from  the  implementation 
(body)  part.  Thus,  even  in  this  early  software  design 
stage,  the  results  can  be  expressed  with  Ada  code. 
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Figure  3:  The  middle  part  of  the  top  level  DFD 


Figure  4;  Refinement  of  the  "flight  management"  with  process  identification 


In  order  to  conclude  the  global  desim,  the 
interactions  of  the  tasks  have  to  be  specified.  The  data 
flows  between  the  concurrent  processes  are  a  basis  for 
the  Ada  rendezvc  ^  between  these  tasks.  In  this 


design  step,  a  careful  decision  has  to  be  made  as  to 
which  task  issues  an  entry-call  and  which  task  is  called, 
to  avoid  waitmg  tasks  and  dead-locks  (caller-called 
decisions). 
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Figure  5:  Ada  task  graph  of  the  main  CPU 


The  final  result  of  such  a  ^obal  design  is  an  Ada 
task  graph  (ATG)  which  describes  the  network  of  all 
concurrent  processes  and  their  interactions.  In  an 
ATG,  bubbles  now  represent  tasks,  their  connection 
arrows  represent  the  call  directions  and  the  small 
arrows  describe  the  data  flows.  See  figure  S  for  an 
example  ATG  from  the  helicopter  project.  All  pre¬ 
viously  identified  processes  appear  here  on  a  single 
level  (no  hlerarclw).  The  handler  processes  of  the  first 
design  step  now  fit  into  the  gradually  identified  pro¬ 
cesses  of  the  main  avionic  part.  The  sometimes  com¬ 
plicated  distribution  of  the  processes  onto  processors 
m  a  multiprocessor  environment  is  beyond  the  scope 
of  this  pa^r.  For  an  extension  of  this  design 
methoaology  to  distributed  environments,  see  |2|. 

In  the  expenmental  helicopter  project,  the  multi¬ 
processor  setup  was  straigntforward;  the  main  CPU 
(master)  performs  all  applications  while  two  other 
processors  are  dedicated  to  graphics  management  and 
report  writing.  In  general,  it  should  be  possible  to 
represent  all  processes  of  a  single  processor  in  a  single 
level  ATG.  Otherwise,  too  much  concunency  (too 
many  Ada  tasks)  will  occur.  As  an  example  of  the 
caller-called  decision,  consider  the  interactions  of  the 
flight  control  and  the  terminal  management  process  of 
figure  S;  the  flight  control  process  is  a  pure  server,  i.e. 
is  always  called  in  order  to  be  in  an  accept  mode  for 
its  various  jobs  at  any  time  (in  Ada,  this  corresponds 
to  a  selective  wait  construct).  On  the  other  hand,  the 
terminal  management  process  is  a  pure  caller.  It 
performs  lengthy  computations  accessing  lots  of  data. 
Therefore,  it  always  actively  issues  Ada  entry  calls.  In 
conclusion,  both  interactions  between  the  flight 
control  and  the  terminal  management  process  are 
called  from  the  terminal  management  side,  although 


the  data  flow  is  in  one  case  “in’  and  in  the  other  case 
“out". 


4,  Detailed  design 

As  already  mentioned,  compilable,  top-level  Ada 
code  can  easily  be  deduced  from  the  ATG  oy  descri¬ 
bing  concurrent  processes  with  Ada  tasks  and  their 
interactions  with  Ada  rendezvous.  Performing  the 
detailed  design,  the  Ada  package  construct  is  applied 
in  conjunction  with  OOD  ideas. 

In  a  first  step,  the  Ada  tasks  are  encapsulated  in  Ada 
packages.  So-called  “entrance  procedures'  are  the  only 
visible  parts  of  the  concurrent  processes  in  the 
package  specifications.  Not  until  the  package  bodies 
are  the  tasks  themselves  declared  ana  their  entries 
identified  with  the  entrance  procedures.  Hence,  the 
tasks  are  treated  as  typical  objects  in  an  OOD 
manner;  their  detailea  definition,  or  even  their 
implementation  is  not  visible.  Only  the  operations 
which  influence  them,  i.e.  the  entrance  procedures, 
are  visible.  Figure  6  shows  this  OOD  concept  applied 
to  the  moding  part  of  the  ATG  of  figure  5. 

In  the  following  steps,  the  sequential  flow  of  each  task 
is  further  decomposed  using  separate  Ada  sub¬ 
programs  (which  describe  some  DFD-transforms  of 
the  task)  and  again  using  Ada  packages  and  proce¬ 
dures  /  functions  to  represent  objects/operations 
from  OOD  theory.  For  example,  the  height  warning 
(figure  4)  will  be  implemented  as  a  separate  sub¬ 
program  in  the  task  'navigation'. 
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Spec.*  \  with  DEVICES;  -  -  Definition  of  devices  and  their  status 
^  package  MOOING  is 

^  typo  MASTER.MOOE  is  (OFF.  DAY,  NIGHT, . .  ); 

\  type  MODES  is . . .; 

I  function  GET_MODES  return  MODES:  -  -  access  to  data  store 
\  -  -  entrance  procedures: 

I  procedure  NEW.MASTER,MODE  (VALUE  :  in  MASTER.MODE) 

^  end  MOOING; 

Body:  |  package  body  mooing  is 

^  task  MOOING  is 

<  entry  NEW.MASTEFLMODE  (VALUE  :  in  MASTER_MODE); 

I  end  MOOING; 

I  procedure  NEW.MASTER.MODE  (VALUE  :  in  MASTER_MODE)  is 

i  begin 

?  MODING.NEW.MASTER.MODE  (VALUE): 

^  end  NE\W.MASTEFLMODE; 

\  task  body  MOOING  is  separate: 

<  end  MOOING; 


Figure  6:  An  example  for  using  OOD  techniques  in  Ada 


This  concludes  the  discussion  about  the  design 
method.  The  further  stepwise  refinement,  towards  a 
full  Ada  implementation  is  generally  straightforward 
and  heavily  depends  on  the  specifics  of  the  appli¬ 
cation.  The  next  chapter  returns  to  the  discussion 
of  the  most  dominant  feature  of  this  design  method: 
the  real-time  scheduling  aspect. 


S.  Scheduling  with  the  Ada  tasking  model 

Earlier  avionic  projects,  especially  those  where 
strict  real-time  requirements  with  short  cycle  times 
dominated,  were  typically  realized  using  a  dobal 
CTclical  scheduler.  All  functional  modules  Bad  to  be 
fitted  into  time  slots  of  a  cyclical  executive  in  order  to 
guarantee  their  periodicity  and  to  ensure  that  the 
critical  -ections  of  different  tasks  do  not  interleave. 
With  largei  .ipplications,  this  mapping  process,  from  a 
function^  aspect  to  time  slice  benaviour,  became 
more  and  more  complicated.  The  average,  or  better 
the  worst  case  duration  of  each  function,  had  to  be 
estimated  to  ensure  that  all  applications  fit  into  their 
lime  slots.  An  overrun  would  destroy  the  whole  j^obal 
execution  scheme.  Such  an  approach  often  confused 
clear  program  structure,  violating  functional  cohesion 
and  locality  principles  for  the  sake  of  timing  con¬ 
siderations.  Typic^y,  such  schedulers  were  imple¬ 
mented  using  special  operating  system  routines  or 
real-time  extensions  to  the  implementation  language. 


The  Ada  tasking  model  cfiers  a  fundamentally 
different  approach.  As  observed  in  the  previous 
chapters,  the  language  ilselif  provides  all  the  features 
necessary  for  rem-time  scheduling.  Whenever  a  task 
completes  an  execution  part,  has  to  wait  for  infor¬ 
mation  from  other  tasks,  or  a  higher  priority  task 
becomes  rea^  to  execute,  the  system  automatically 
reschedules.  This  dynamic  preemption  of  tasks  at  run¬ 
time  is  a  direct  outcome  of  the  Ada  compiler.  It 
generates  non-dcterministic  timelines,  at  odds  with 
the  very  idea  of  the  classical  fixed  execution  time  slots. 

As  we  have  observed,  the  design  of  real-time 
systems  using  Ada  is  guided  by  functional  cohesion. 
Only  those  software  modules  whose  applications  are 
related,  comprise  a  common  task.  Each  task  locally 
determines  its  real-time  behaviour.  Some  execute 
event-driven,  others  periodically,  locally  setting  up 
their  cyclical  behaviour.  No  global  scheduler  ifcter- 
mines  the  system  flow,  only  the  rendezvous  mecha¬ 
nism  between  the  tasks  guides  the  flow  of  execution. 
Each  task  schedules  itself,  either  cvclically  with  the 
Ada  construcu  ’delay”  and  "calendar.clocK’  or  on 
event  per  rendezvous  "accept"  or  call.  Therefore, 
CTclical  behaviour  is  naturally  integrated  with  event 
driven  processes.  Overall,  such  an  Ada  design  can  be 
easily  extended  and  with  the  help  of  the  locality 
principle  and  OOD  constructs  many  modules 
(packages)  are  reusable. 

Early  criticism  of  Ada’s  real-time  features  argued 
that  the  non-determinism  of  the  Ada  tasking  model 
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was  in  contradiction  to  fixed  real-time  deadlines. 

But,  extensive  studies  have  proved  that  certain  bounds 
on  CPU  utilization,  in  conjunction  with  Ada  priority 
licies,  guarantee  that  all  tasks  will  meet  their  dead- 
es  without  knowing  exactly  when  any  given  task  will 
be  running  (see  [3]).  Without  going  into  details  of  this 
study  here,  the  principle  ideas  of  the  study  [3j  are  the 
“rate  monotonic  scheduling  algorithm",  which  ^ves 
each  task  a  fixed  priority  assigning  higher  priorities  to 
tasks  with  shorter  periodicity,  and  the  “priority  ceiling 
protocol",  which  prevents  dead-lock  situations  and 
unwanted  priority  inversions.  Nevertheless,  the 
present  definition  of  the  Ada  lan^age  has  some 
drawbacks  related  to  the  priority  inversion  issues 
(which  are  caused  by  using  FIFO  rather  then  priority 
queues  for  tasking).  Hopefully,  future  versions  of  Ada, 
and  perhaps  even  the  next  official  release,  Ada9X,  will 
address  this  matter. 

A  second  important  criticism  regarding  Ada’s 
real-time  execution  was  the  unsatisfactory  nuality  of 
the  Ada  compilers.  How  big  of  an  overhead  does  an 
Ada  compiler  impose  on  the  scheduling  (task  switch 
times)?  A^at  is  the  accuracy  of  the  delay  and  timer 
constructs  in  Ada?  Benchmark  tests  initialized  by 
SIGAda’s  performance  is.sues  working  group  show 
that  the  latest  generation  of  compilers  now  have  quite 
satisfactop'  results  (see  [4]).  Our  own  experience  m 
the  experimental  helicopter  project  was  also  quite 
satisfying.  The  Ada  tasking  model,  under  the  rate 
monotonic  scheduling  policy,  i.e.  a  special  polity  of 
assigning  priorities  to  tasks,  works  well.  Nevertheless, 
a  few  features  of  an  Ada  runtime  .system  outside  the 
scope  of  the  language  were  used,  especially  to  over¬ 
come  the  inaccuracy  of  the  Ada  timer  resolution. 


6.  Conclusion 

The  experimental  helicopter  project,  as  a  typical 
real-time  system,  has  been  completely  designed  and 
implemented  with  Ada.  The  design  method  derived 
from  Nielsen  /  Shumate  has  proved  to  be  a  practical, 
comprehensive  guideline  utilizing  the  powerful  Ada 
features  to  define  and  implement  a  complex  real-time 
software  system. 

The  functional  decomposition  served  as  a  basis 
to  build  the  Ada  tasks  and  their  rendezvous.  In  this 
process,  non-cycUcal  modules  and  periodic  tasks  were 
easily  combined.  Hence,  no  painful  fitting  of  func- 
lionm  applications  in  time  slots  of  a  cyclical  executive 
had  to  DC  performed.  The  Ada  compiler  itself  pro¬ 
vided  the  real-time  scheduling. 

Currently,  the  project  is  undergoing  a  restruc¬ 
turing  phase  leading  to  some  new  or  changing  func¬ 
tionality  and  requirements.  But,  because  of  the  well 
structured  desi^  and  the  modular,  clear  and  reusable 
software  implementation,  due  to  Ada,  we  are 
convinced  that  we  can  easily  cope  with  these  new 
aspects. 


References 

[1]  Kjell  Nielsen,  Ken  Shumate 

“Designing  Lmge  Real-time  Systems  with  Ada“ 
McGraw-Hill,  1988 

[2]  Kjell  Nielsen 

"Ada  in  Distributed  Real-time  Systems" 
McGraw-Hill,  1990 

J3]  L.Sha,J.B.Goodcnough(SEI,CMU) 

"A  Review  of  Analytic  Real-time  Scheduling 
Theory  and  its  Application  to  Ada" 
Proceedings  of  the  Ada-Europe  International 
Conference,  1989 

(4]  SIGAda  Performance  Issues  Working  Group 
"Ada  Performance  Issues" 

ACM  Press  Ada  Letters  No.  3, 1990 


I 


17- 1 

CODE  GENERATION  FOR  FAST  DSP-BASED  REAL-TIME  CONTROL 
by 

H.  Hanselmann.  A.  Schwane,  H  Henrichfreise 
dSPACE  digilal  signal  processing  and  control  engineering  GmbH 
An  der  SchSnen  Aussicht  2 
W-4790  Paderbom 
Germany 


t 

i 


Summary.  Digital  single-chip  signal  processors  (DSP)  are 
powerful  devices  to  implement  closed-loop  controllers  for 
htghly  dynamic  mechanisms.  Code  production  is  however  not 
that  easy,  particularly  with  DSP  offering  only  fixed-point 
arithmetic.  This  paper  describes  key  issues  and  a  toolset  which 
builds  on  automatic  code  generation  to  complement  existing 
control  design  tools  so  as  to  close  the  gap  between  design  and 
implementation  or  experiment. 


Introduction 


An  integral  part  of  many  guidance  and  control  tasks  is  the 
lower  level  embedded  closed-loop  control  of  mechanisms 
(Fig.  1). 

reference  and 
feedforward  signals 


ontrbller  ■  ■  H  actuators  ^ 


mechanism 


I 


controlled  and  auxiliary  variables 


Fig.  1;  closed-loop  control 


The  mechanisms  conu’olled  may  range  from  microminianire 
actuators  to  huge  flexible  space  structures.  Tasks  include 
motion  control,  vibration  damping,  and  stabilization.  Tech- 
ntques  include  classical  multiloop  PlO-control,  state-space 
contiol  with  Kalman-Filters  and  observers,  gain-scheduling, 
and  adaptive  control. 

Fixed-point  and  floating-point  digital  signal  processois  (DSP) 
are  veiy  powerful  devices  for  implementation  of  such  con¬ 
trollers  for  fast  systems.  They  are  also  available  in  high-relia- 
bility  versions  suitable  for  avionics  and  similar  applications. 

Traditionally,  the  code  for  such  devices  is  developed  on  the 
assembly  language  level  which  has  well-known  disadvantages. 
For  fixed-point  DSP  there  has  been  vinually  no  alternative. 
There  are  HLL  (high  level  language)  compilers  for  some  DSP, 
but  they  lack  adequate  data  lyiies  for  dealing  with  fixed-point 
arithmetic  other  than  integer.  Tliey  are  also  not  tailored  to  the 
architecture  of  DSP.  Funhermore,  producing  code  for  such 
processors  means  more  than  just  programming.  There  is  much 
to  be  done  between  a  completed  controller  design  and  the  point 
where  actual  code  can  be  produced.  Crucial  steps  are  structure 
selection  and  scaling. 

For  the  newer  floating-point  DSP  there  are  quite  good  C 
compilers  and  the  specifics  of  fixed-point  arithmetic  no  longer 
dominate  the  task  of  code  production.  More  complex  nonlinear 
control  can  be  envisioned  to  be  implemented  fully  automatical¬ 


ly,  whereas  for  fixed-point  chips  fully  automatic  implementa¬ 
tion  is  cuiTcntly  limited  to  linear  (though  arbitrarily  high-order) 
controllers,  with  semi-automatic  treatment  of  nonlinearities  and 
logic. 

This  paper  describes  key  issues  and  a  powerful  commercially 
available  toolset  (DSP-ClTpro)  for  generating  code  for  re¬ 
al-time  DSP-based  control.  This  toolset  has  also  proven  to  bo 
very  useful  for  real-time  simulation  (hardware-in-the-loop 
simulation). 


DSP  Chip  Categories 

The  largest  DSP  family  is  available  from  Texas  Instraments. 
This  family  roughly  divides  into  three  groups  (Fig.  2). 

^  floMne  PoW  DSP  ^ 


Fixed  Poetl  DSP  )  {  Fixed  Point  DSP  Micxixonliollei 


Fig.  2:  DSPeategones 

The  DSP  microcontroller  is  just  a  fixed-point  DSP  with  on-chip 
peripherals  such  as;  bit  i/o  port,  watchdog,  6  high-speed 
pulse-width-modulated  outputs.  4  capture  inputs.  The  latter  two 
features  belong  to  a  so-called  event  manager,  a  very  important 
subsystem  which  is  also  available  in  many  modem  non-DSP 
microcontrollers 

The  most  important  points  of  a  DSP’s  architecture  regarding 
code  generation  arc: 

-  the  type  of  arithmetic  offered, 

-  the  support  for  HLLs  (high  level  languages), 

-  memory  limitations. 

1'hc  current  floating-point  DSPs  ate  most  suitable  for  standard 
HLLs  such  as  C.  They  have  vinually  no  memory  limitations, 
software  stack  support,  and  veiy  efficiently  implement  the 
floating-point  anthmetic  of  standaid  HLLs. 

Standard  HLLs  are  not  generally  suited  to  fixed-point  DSP 
primarily  because  they  do  not  offer  a  suitable  data  type  and 
arithmetic  concept  for  efficient  and  accurate  fixed-point  signal 
processing.  The  DSPL  language  as  desenbed  below  is  designed 
specifically  to  fill  this  gap.  It  also  addresses  other  issues  of 
efficient  use  of  the  DSP’s  special  architecture  and  instruction 
set/1/ 


Fixed-point  DSP  Anthmetic 

The  anthmeuc  used  throughout  DSP-ClTpro  for  fixed-point 
DSP  is  fractionai  arithmetic  where  the  binary  point  is  just  right 
of  the  ’sign’  bit  (Fig.  3), 
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Fig  3  fractional  data  format 
anil  the  number  range  is 
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The  central  anthmeuc  operation  in  most  signal  processing  tasks 
IS  the  scalar  (or  dot)  product 

r  =  c, •d|  +  e2di+  ® 

It  is  crucial  to  have  a  clear  methodology  as  to  how  this 
operation  is  to  be  implemented  on  a  DSP,  with  respect  to 
number  range  violations,  accuracy,  and  efficiency. 

Key  Issues  of  Control  Implementation 

From  a  system  dynamics  viewpoint  some  key  issues  when 
implementing  a  closed-loop  controller  are  /2/’ 

( 1 )  minimization  of  computational  load, 

(2)  insensitivity  to  coefficient  and  signal  quanuzation, 

(3)  minimization  of  input/output  delay, 

(4)  good  discretization  if  controller  prototype  design  is 
analog, 

(5)  adequate  scaling  for  fixed-point  anthmetic, 

(6)  overflow  handling  with  fixed-point  imithmelic. 

From  a  coding  viewpoint  some  key  issues  are' 

(7)  avoiding  assembly  language  coding,  yet  exploiting  pro¬ 
cessor  architecture, 

(8)  avoiding  loops,  subroutines,  or  indexing  for  maximum 
speed, 

(9)  control  over  memory  allocation, 

(10)  ensunng  timely  execution  even  for  worst-case  control 
flow  in  the  program, 

(11)  avoiding  extended  precision  arithmetic 


Remark  (8)  may  seem  to  contradict  good  programming  prac¬ 
tice,  but  need  not  have  the  unwanted  effects  normally  associat¬ 
ed  with  such  programming  style  For  DSPL  compilers  as 
described  below  the  level  where  this  style  becomes  visible  is 
the  assembly  language  output,  not  the  DSPL  program.  For 
generated  C  code  the  generated  code  is  still  easy  to  read. 

The  various  points  listed  above  will  now  be  explained  in  some 
detail  first  for  a  linear  controller.  It  is  assumed  that  the 
controller  is  available  in  the  fonn  of  matnces  4 ,  B .  C.  O  of  the 
time-invanant  difference  equation 

Xn,=Ax^-rBu^  (1) 

y^  =  Cx^  +  Du, 

where  x  is  the  internal  state  vector  of  tne  controller  (which  is 
assumed  to  have  dynamics,  not  just  gams),  u  comprises  all 
input  signals  to  the  controller  (i  e.  from  sensors  or  reference 
generators  /  path  planning  modules),  and  y  comprises  all 


external  outputs  of  the  controller  (i  e  at  least  the  control  signals 
going  to  the  actuators). 

If  the  controller  is  a  connection  of  subsystems  then  it  is 
assumed  for  simplicity  that  all  subsystems  and  connections  are 
combined  into  one  big  ’monoblock’  system  (1).  An  example 
would  be  the  connection  of  a  state  feedback  gam  matnx, 
feedforward  gam  matnx  and  a  plant  observer  or  stationary 
Kalman-Filter.  A  great  deal  of  what  is  explained  below  would 
also  apply  if  only  a  linear  subsystem  of  a  nonlinear  controller 
would  be  considered. 

(I)  minimization  of  computational  load 

If  matnces  4,  B,  C,  D  are  taken  directly  from  a  control  design 
software  package,  then  all  matnces  may  be  totally  dense  m  the 
worst  case.  Minimization  of  the  computational  load  means 
reducing  the  number  of  nonzero  entnes  (coefficients)  in  those 
matnces,  without  altcnng  anything  m  the  dynamic  input/out- 
put-behaviour  of  the  controller  This  can  be  achieved  by 
suitable  transiormations  based  on  linear  algebra  theory  Matn¬ 
ces  4.  B.C  are  affected  Totally  dense  matnces  4 ,  C  may  for 
example  be  changed  into 

'0  0  0  0  0  -a/ 

10  0  .0  0  -a, 

0  1  0  ..  0  0  -a, 

A  =  ■ 

0  0  0..  10  -a..j 

0  0  0  .  .  0  1  -a.., 


C=(0  0  0  ..  0  0  1) 

The  various  forms  of  the  matnces  are  also  called  structures  due 
to  their  different  block  diagrams  when  represented  graphically 

Unfortunately,  such  transformations  ii  ly  have  an  adverse  effect 
on  sensitivity  to  quantization  in  the  processor.  It  is  important  to 
have  tools  which  provide  adequate  structures,  and  can  analyse 
sources  of  potential  or  real  trouble  with  quantization 

(2)  insensitivity  to  coefficient  and  signai  quantization 

Different  structures  in  the  above  sense  nomially  exhibit  differ¬ 
ent  sensitivity  to  coefficient  and  signal  quantization  Quite 
frequently  the  structures  with  the  least  number  of  nonzero 
coefficients  behave  very  badly  m  this  respect.  With  such  a 
structure  one  may  be  forced  to  use  extended  precision  arith¬ 
metic  somewhere,  which  quickly  outweighs  any  gam  from 
reducing  the  number  of  nonzero  coefficients 

(3)  minimization  of  inputi output  delay 

If  the  conhol  signal  instantly  depends  on  current  sensor  input 
samples,  which  is  nonnally  the  case  with  controllers,  then  there 
.s  some  inevitable  delay  between  the  theoretical  output  instant 
and  the  real  one  (Fig.  4). 


Some  of  the  delay  may  be  due  to  AT)-  or  D/A-converters  and  is 
unavoidable  The  delay  resulting  from  the  finite  computa'ion 
time  in  the  processor  however  can  be  minimized  by  proper 
arrangement  of  tlie  code  (Fig  5) 
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ideal  real 


Fig.  4;  inpul/output  delay 


i.e.  by  inlroduction  of  normalized  variables  after  determining 
maximum  values. 

Even  with  scaling  of  variables  it  is  not  guaranteed  that  the 
coefficients  of  scalar  products  are  all  ftactional  numbers.  For 
matncesd.B  in  (I)  this  can  however  normally  be  expected  with 
certain  structures  (which  are  often  anyway  the  preferable  ones), 
such  as  the  so-called  real-modal  form.  For  C,  D  this  is  often  not 
the  case.  The  frequently  high  gains  of  a  controller  are  repre¬ 
sented  in  these  matrices,  and  coefficients  three  orders  of 
magnitude  greater  than  one  (the  fractional  number  limit)  have 
been  experienced.  Scalar-product  handling  as  mentioned  below 
helps. 
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Fig.  5:  inpul/output  delay  minimization 


(6)  overflow  handling  with  fixed-point  arithmetic 

With  a  scalar  product  (2)  there  is  the  potential  of  overflow. 
Even  with  proper  scaling  of  variables  such  asx.y  in  (1)  there 
may  still  be  some  variables  which  may  overflow  occasionally, 
and  this  may  even  be  intentional.  An  example  is  the  control 
signal  to  the  actuator  of  a  position  control  system.  With  large 
commanded  position  changes  the  control  signal  is  normally 
expected  to  saturate  for  a  while  This  means  that  this  compo¬ 
nent  of  y  must  be  able  to  go  into  saturation  overflow.  The  same 
may  hold  for  components  of  x  if  they  are  associated  with 
integrators  in  the  controller 

Unfottunalcly  wrap-around  will  occur  if  no  provision  for 
overflow  saturation  is  made  (Fig  6). 
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Fig.  6:  overflow  handling 


(4)  good  discretisation  if  controller  prototype  design  is 
analog 

if  control  design  is  carried  out  in  the  continous  domain  (t.e.  for 
analog  implementation)  the  controller  will  normally  be  dis¬ 
cretized,  I.e.  the  differential  equations  will  be  translated  into 
difference  equations.  Much  can  be  gained  by  using  methods 
which  have  proven  to  produce  good  discretizations.  A  good 
discretization  is  one  which  does  not  alter  the  controller's,  or 
more  importantly,  the  closed-loop's  behaviour  when  compared 
to  the  analog  one.  Experience  has  shown  that  a  good  method 
can  yield  as  much  as  a  factor  of  five  reduction  in  the  required 
sampling  rale  over  a  standard  discretization. 

(5)  adequate  scaling  for  fixed-pomt  arithmetic 

Controller  implementation  on  fixed-point  DSP  requires  proper 
scaling  of  coefficients  and  variables.  Coefficients  must  be 
representable.  V"..iables  (signals)  must  be  scaled  in  order  to 
avoid  bolli  excessive  quantization  for  small  signals  and  over¬ 
flow  for  large  signal  exclusions. 

Scaling  of  u,y  in  (l)is  nonnally  derived  from  the  gains  of 
A/D-  and  D/A-conveners  and  sensor  and  actuator  amplifier 
gains.  Proper  scaling  of  x  ai  be  detemiined  by  various  means. 
One  particularly  attractive  method  is  the  so-called  I, -scaling.  It 
can  be  earned  out  by  an  algorithm  (in  DSP-CITpro)  completely 
automatically. 

Scaling  of  nonlinear  expressions  (as  may  be  attached  to  an 
otherwise  linear  conuoller)  is  presently  carried  out  manually 
along  the  same  lines  as  known  to  some  from  analog  computing. 


The  code  generation  for  fixed-point  DSP  in  DSP-ClTpro  via 

the  DSPL  language  provides  a  systematic  method  called 

scaiar-product  scaling  at  compile  time  to  guarantee 

•  accommodation  of  coefficientt  outside  the  fractional  number 
range, 

-  efficient  and  accurate  execution  of  the  scalar-product  opera¬ 
tion  in  the  extended  accumulator  of  the  DSP, 

-  creation  of  logical  'guard'  bits  to  ensure  proper  saturation  on 
overflow,  if  desired. 

(7)  avoiding  assembly  language  coding,  but  still  exploiting 
processor  architecture; 

(8)  avoiding  loops,  subroutines,  or  indexing  for  maximum 
speed. 


A.  Floating-Point.  For  floating-point  DSP,  which  offer  32-bit 
single-precision  computation  without  speed  penalty,  the  pre¬ 
dominant  HLL  IS  C,  but  there  are  also  compilers  for  other 
languages.  For  the  TMS  320C30  there  is  even  an  Ada  compiler 
available.  So  there  is  normally  no  need  for  assembly  language 
progranuning  except  maybe  for  increased  speed  or  in  case  of 
very  tight  memory  lumlations  of  the  target  hardware. 

Standard  HLL  compilers  naturally  lack  special  constructs 
useful  for  mapping  signal  processing  operations  onto  the 
special  architecture  of  a  DSP.  0).  iizations  available  in 
modem  compilers  can  however  considerably  improve  runtime 
efficiency  /3/. 
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As  an  example  a  FIR  filter  operation  is  considered  which  is 
desenbed  by  the  equation  below,  where  y  is  the  filter  output,  a, 
are  the  coefficients,  and  u  holds  the  current  and  previously 
stored  values  of  the  sampled  input  signal. 

The  tasks  to  be  performed  are 

-  computation  of  the  output  by  the  scalar  product,  as  a 
sequence  of  coefficient-times-input-vanable  multiplications 
and  partial  product  accumulations, 

-  moving  the  stored  mput  values  u,  so  as  to  introduce  the 
newest  input  sample  and  discarding  the  oldest, 

A  DSP  such  as  the  TMS  320C30  can  perform  this  operation  in 
one  cycle,  although  there  is  some  setup  and  pipelining  overhead 
which  IS  significant  for  short  filter  lengths.  Fig.  7  shows  the 
assembly  language  code  which  makes  use  of  parallel  execution 
of  3-operand  multiply  and  add  plus  address  generation  for  both 
coefficients  and  input  samples  m  one  cycle  (the  code  shown  in 


the  box) 

LDI 

filter_order  -f  1 ,  BK  ;  block  size  n  + 1 

LDI 
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cient 
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L  LDF 
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R3,  * AR 1  ++%  ,  u.newest  ->  buf 

LDF 

0.0,  RO 
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00,  R2 

RPTS 

filter.order  ; 

n 

MPYF3 

*AR0-t-f(l)%,  •ARl-i-+(l)%,  RO 

II  ADDF3 

RO,  R2,  R2 

ADDF  RO,  R2  ;  accumulate  last  product 

STF  R2,  y_k 

B  L 

Fig.  7  optimal  FIR  filter  assembly  code  for  TMS  320C30 

A  problem  with  a  HLL  like  C  is  that  the  compiler  is  not 
intelligent  enough  to  detect  that  a  piece  of  C  code  actually 
represents  a  FIR  filter  and  could  be  compiled  into  the  above 
code  With  optimizations  enabled,  the  Texas  Instruments  C 
compiler  produces  code  which  is  approximately  4  times  slower 
than  the  above  assembly  program.  The  compiler  is  unable  to 
generate  parallel  multiply  and  add  operations  (factor  2)  and  the 
’update’  operation  (u,--su,.,)  is  executed  separately.  This  is 
because  the  ’update’  must  be  formulated  in  a  separate  statement 
m  C,  whereas  at  the  assembly  language  level  a  special  DSP 
addressing  mode  (circular  addressing)  can  be  exploited  The 
compiler  is  however  intelligent  enough  to  introduce  zero-penal¬ 
ty  looping,  parallel  address  increment,  and  a  delayed  branch. 

For  less  structured  operations  the  speed  penalty  of  such  a 
modem  optimizing  HLI,  compiler  should  be  rather  low. 

In  general  there  are  some  basic  rules  to  follow  for  maximum 
efficiency,  such  as 

(a)  to  avoid  calculating  with  insignificant  coefficients, 

(b)  to  avoid  loops, 

(c)  to  avoid  vanable  indices, 

(d)  to  avoid  pointers, 

(e)  to  avoid  unnecessary  function  calls 

Some  of  these  rules  can  normally  not  be  met  with  ’general’ 
subroutines  using  loops  and  arrays  So-called  ’straight-code’ 
should  be  used,  which  is  best  produced  by  generating  programs 
from  higher  level  descriptions  of  the  tasks.  Violating  these  rules 


may  result  in  severe  degrading  of  execution  speed.  The 
computing  power  of  a  DSP  can  quickly  be  turned  into  a 
fraction  of  the  peak  MFLOPS  rate  by  not  letting  the  DSP 
compute,  and  doing  address  computation,  stack  administration 
and  branching  instead. 

6.  Fixed-Point  For  fixed-point  DSP  there  are  only  few 
offerings  of  HLL  compilers.  The  newer  generations  are  some¬ 
times  supported  by  C  compilers  too.  The  statements  on  C 
compilers  for  floating-point  DSP  hold  again,  but  there  is  one 
very  important  additional  point  to  make'  Standard  C  compilers 
have  no  support  for  doing  signal  processing  arithmetic  effi¬ 
ciently,  i.e.  there  is  no  support  for  fractional  number  arithmetic 
and  scalar  product  computation 

There  is  one  C  compiler  available  from  Analog  Devices  for 
their  own  line  of  fixed-point  DSP  which  offers  ’fractional’  as  a 
non-standard  data  type.  But  it  still  lacks  features  for  optimal 
scalar  product  computanon  as  built  into  DSP-CITpro’s  DSPL 
compilers  It  is  not  uncommon  to  see  a  C  programming  effort 
on  a  fixed-point  DSP  ending  up  in  80%  (hand-wntten)  assem¬ 
bly  language  code. 

The  approach  taken  in  DSP-ClTpro  is  to  provide  a  suitable 
intermediate  language,  called  DSPL.  Details  on  syntax  and 
semantics  of  DSPL  can  be  found  in  /!/.  Code  examples  are 
found  below.  A  short  characterization  of  DSPL  and  its  compil¬ 
ers  is 

-  emphasis  on  efficient  and  accurate  fixed-point  scalar  product 
arithmetic, 

-  self-documentation,  Ada/Pascal  like  syntax, 

-  strongly  typed  language, 

-  assembly  language  code  is  generated  without  loops,  subrou¬ 
tines  and  address  calculations  for  maximum  speed, 

-  includes  scalar  product  scaling  mechanism, 

-  hides  mechanisms  for  low-level  operations  such  as  details  of 
signal  i/o, 

-  looping,  decisionmaking,  and  boolean  instructions  available, 

-  interrupt  servicing  on  language  level, 

-  compilers  are  processor  dependent  but  not  hardware  environ¬ 
ment  dependent  (i.e.  target  hardware  may  vary), 

-  compiler  output  is  comprehensively  commented  assembly 
language  program, 

-  global  and  statement-wise  execution  time  profiles  and 
memory  statistics  generated  by  compiler  (see  below). 

DSPL  compilers  are  available  for  first  and  second  generation 
Texas  Instruments  DSPs 

(10)  ensure  timely  execution  even  for  worst-case  control  flow 
in  the  program 

A  closed-loop  controller  or  similar  signal  pnxiessing  system 
must  normally  run  exactly  at  a  fixed  sampling  rate.  It  is  an 
issue  to  determine  the  minimum  execution  time  necessary.  It  is 
also  interesting  to  have  profile  infonnation  to  see  which  pans 
of  the  program  are  the  most  nme-consuming  and  could  possibly 
be  improved. 

The  DSPL  compilers  automatically  provide  this  information. 
For  each  task  a  global  worst-case  execution  time  is  computed 
There  are  some  very  rare  circumstances  where  the  compiler 
cannot  compute  such  information  One  example  is  a  loop  where 
the  repeat  count  is  a  vanable.  In  most  cases  encountered  in 
control  implementation  the  calculation  is  valid.  It  even  takes 
into  account  that  a  DSP  may  have  quite  complicated  mstruction 
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cycle  tables  with  dependencies  on  memory  layout. 

In  addition  the  DSPL  compilers  also  provide  execution  cycle 
infonnation  statement  by  statement  (DSPL),  embedded  as 
comments  in  the  generated  assembly  language  source. 

With  the  C  compiler  for  the  floating-point  DSP  there  is 
unfonunately  no  such  mechanism.  The  code  must  be  executed 
for  real-time  profiling.  A  DSP-ClTpro  module  called  TRACE 
can  however  be  used  to  gather  such  information  from  the 
running  DSP  program  quite  easily.  A  graph  of  the  execution 
time  history  versus  time  can  be  produced,  clearly  showing 
possible  fluctuauons  in  execution  time.  Fluctuations  occur 
when  operations  depend  on  the  actual  numerical  values  of 
operands,  or  if  the  program  control  flow  varies.  Worst-case 
paths  in  the  program  control  flow  can  however  only  be  assessed 
if  they  are  acwally  executed. 

’Executing’  a  program  on  a  DSP  software  simulator  (instruc¬ 
tion  level)  could  be  considered  an  option,  but  is  usually 
impractical  because  it  is  extremely  time-consuming. 

(II)  avoiding  extended  precision  arithmetic 

A  DSPs  computational  power  can  be  defeated  if  large  parts  of  a 
program  require  extended  precision  over  what  is  provided 
directly  by  the  architecture.  Accumulation  (such  as  in  (2))  is 
normally  performed  already  in  extended  precision  at  no  penal¬ 
ty,  but  results  stored  for  later  use  in  the  program  should  be  at 
the  standard  wordlength. 

There  is  one  notable  case  in  control  where  it  may  be  absolutely 
necessary  to  catiy  out  extended  precision  arithmetic.  High-pre¬ 
cision  motion  control  may  for  instance  require  24  bit  position 
values  on  a  16-bit  DSP.  Using  double-word  arithmetic  through¬ 
out  the  control  algorithm  must  however  be  avoided.  Fortunately 
there  is  a  systematic  way  of  keeping  high-ptecision  position 
values  out  of  the  control  computation  /4/,  except  at  one 
easy-to-handle  place.  It  works  equally  well  whether  the  control 
algorithm  is  of  simple  error-driven  PID  type  or  a  sophtsticated 
optimal  state  variable  controller  including  a  stationary 
Kalman-Filter  or  observer. 


Difference  Equations  or  on-line  Integration 

In  control  implementation  it  is  understood  by  most  engineers 
that  the  algorithm  has  to  be  brought  into  difference  equation 
form.  Control  design  in  the  discrete  domain  delivers  this 
directly.  Control  design  in  the  continuous  domain  requires 
discretization.  In  that  case  it  may  be  a  viable  option  to 
implement  fixed-stepsize  on-line  integration  of  the  differential 
equations,  for  example  with  Euler  or  Runge-Kutta-type  integra¬ 
tors.  Advantages  are: 

•  Parameters  of  the  continuous  system  are  directly  reflected  as 
program  variables,  and  thus  can  easily  be  changed  on-line, 
e.g  for  gain-scheduling. 

By  contrast  such  parameters  arc  normally  spread  out  by 
nonlinear  expressions  onto  the  coefficients  of  a  difference 
equation. 

•  Nonlinear  parts  of  the  differential  equation  are  naturally 
represented  on  the  right-hand  side  of  the  first-order  differen¬ 
tial  equation  system  to  be  uitegraled. 

By  contrast  such  parts  need  to  be  separated  before  discretiza¬ 
tion  and  be  attached  later,  making  the  situation  somewhat 
more  complicated 

•  Sparseness  of  coefficient  matrices  of  a  continuous  system  is 
reproduced. 


With  discretization  sparseness  must  normally  be  separately 
generated  by  transforming  into  a  suitable  structure  (see 
above  section  on  minimization  of  computational  load). 

Disadvantages  with  on-line  integrators  are: 

•  Structure  transformation  and  automatic  scaling  are  not 
directly  available  for  fixed-point  DSP. 

•  Stability  problems  may  occur  for  larger  step-sizes  or  stiff 
systems. 

•  Integration  accuracy  may  be  more  limited,  and  the  fidelity  of 
the  digital  version  of  the  continuous  system  may  be  signifi¬ 
cantly  worse  than  with  a  good  discretization  of  the  linear 
pan. 

It  is  worth  mentioning  that  there  are  discretization  methods  for 
the  linear  pan  which  correspond  to  an  implicit  on-line  integra¬ 
tor  with  respect  to  dynamics.  Such  algorithms  are  interesting 
because  they  do  not  suffer  from  stability  problems  with  stiff 
systems.  Implicit  on-line  integrators  however  are  totally  im¬ 
practical  for  real-time  use. 

On-line  integration  today  is  the  first  choice  for  real-time 
simulation  of  big  nonlinear  mechanical  systems  IS/  on  float¬ 
ing-point  DSP,  where  panicularly  the  first  above-mentioned 
advantages  count. 

Control  Implementation  with  DSP-CITpro 


Die  modules  of  DSP-CITpro  and  their  interplay  are  depicted  in 
Fig-  8. 


Fig.  8:  DSP-CITpro  modules 
A  brief  description  of  the  modules  is  now  given: 

Interface  Software.  DSP-CITpro  does  not  cover  control  design 
or  postprocessing  of  signals  taken  from  the  real-time  experi¬ 
ments  which  may  follow  code  generation.  For  these  purposes 
there  are  well-known  packages  available  such  as  MATRlXx  or 
MATLAB.  DSP-CITpro  interfaces  to  these  packages. 

IMP  AC.  Impac  consists  of  IMPEX  and  a  C  or  DSPL  compiler. 
IMPEX  covers  the  preparation  of  a  linear  controller  and 
analysis  of  implementation  effects,  and  also  generates  a  DSPL 
or  C  program  for  the  controller.  Such  programs  are  then 
compiled  by  the  appropriate  compiler. 

IMPEX.  In  detail  IMPEX  provides  the  following  services: 

-  discretization, 

-  combination  of  subsystem  blocks  into  a  complete  controller, 

-  transfomiation  into  a  suitable  structure, 

-  automatic  coirecnon  for  A/D-  and  D/A-  gams, 

-  automatic  scaling  of  controller  states  for  Exed-point  imple¬ 
mentation, 


-  analysis  of  signal  and  coefficient  quantization  by  simulation, 

-  A/D-  and  D/A-  range  entry  and  assignment  of  physical  to 
logical  i/o  channels, 

-  code  generation  specifications  (memory  layout,  scalar  prod¬ 
uct  scaling  etc,). 

The  IMPEX  sen'ices  are  available  for  linear  blocks  (1)  includ¬ 
ing  saturation  where  desired. 

MERGE.  MERGE  is  a  kind  of  a  batch  editor.  Its  primary  use  is 
to  make  modifications  and  insertions  into  code  which  was 
automatically  generated  by  IMPEX.  A  typical  situation  follows 

A  control  design  will  normally  be  repeated  and  improved  many 
times  based  on  experiment  results.  Current  control  design 
technology  is  focusing  on  linear  control.  So  in  one  design/im- 
plementation/experiment  project  a  lot  of  versions  of  a  linear 
controller  are  generated.  Frequently  the  linear  controller  alone 
is  not  sufficient,  and  must  be  enhanced  by  logic  or  nonlinear 
parts.  Such  parts  are  currently  beyond  the  code  generation 
scope  of  IMPEX,  so  they  have  to  be  added  at  the  language  level 
(DSPL  or  C)  This  editing  is  what  MERGE  can  automate.  A 
suitable  control  file  tells  MERGE  how  to  modify  or  enhance 
the  input  code.  Manual  editing  can  be  avoided  and  very  quick 
turn-around  times  can  be  achieved  even  if  the  logic  and 
nonlinear  control  code  finally  is  much  larger  than  the  code  for 
the  linear  block. 

NMAC.  NMAC  is  currently  only  available  for  the  fixed-point 
DSP.  It  produces  DSPL-callable  assembly  code  for  nonlinear 
univariate  functions  NMAC  reads  a  file  describing  arbitrarily 
spaced  and  arbitrarily  many  sample  points  of  a  desired  func¬ 
tion.  It  then  produces  table-lookup  code  which  is  optimized  for 
accuracy  and  speed.  Various  parameters  specified  by  the  user 
can  tailor  the  code  towards  speed,  accuracy,  and  memory 
consumption  tradeoffs 

DSPL  Compiler.  The  important  features  have  already  been 
discussed  in  the  general  section  on  code  generation.  More 
information  is  embedded  in  the  examples  below.  The  code 
ouiput  of  the  DSPL  compiler  is  fully  commented  assembly 
code  including  execution  time  profile  information.  The  assem¬ 
bly  code  is  assembled  by  a  standaid  assembler. 

C  Compiler.  The  Texas  Instruments  ANSI  C  compiler  is  used 

MON  and  SED  MON  is  an  object  code  loader.  It  also  loads 
setup  information  into  the  DSP-CITpro  hardware  Such  setup 
information  (A/D-ranges  etc.)  is  bound  to  the  object  code  so 
that  loaded  cc.ie  and  loaded  setups  are  always  consistent.  SED 
is  a  setup  editor.  It  is  normally  only  used  for  static  hardware 
setup  data.  Setuti  data  for  individual  controllers  are  normally 
produced  at  the  v'.)de  generation  stage  of  IMPEX. 

TRACE.  TRACE the  module  used  to  record  all  desired 
variables  in  the  DSP  while  the  conuol  application  is  running.  It 
could  be  desenbert  as  a  virtually  non-intrusive  software  tran¬ 
sient  recorder.  Sophisticated  triggering  features  allow  captunng 
the  relevant  data.  Such  data  can  be  displayed  graphically  or 
turned  over  to  signal  analysis  or  system  identification  packages 
(MATLAB  for  example) 

In  sununary,  the  DSP-ClTpro  modules  fill  the  gap  between 
theoretical  conuol  design  and  the  real  experiment  Turnaround 
times  are  very  short  due  to  sophisticated  tools  for  making  a 
controller  suitable  for  implementation  and  due  to  code  genera¬ 
tion.  It  need  not  take  more  than  a  couple  of  minutes  to 
reimplement  a  redesigned  high-oider  state  controller  including 
a  stationary  Kalman-Filter  up  to  and  including  the  actual 
experiment. 

DSP-CITpro  has  been  used  in  many  fields  of  application  and 
for  various  control  techniques  A  selection  of  such  applications 


with  relevance  to  aerospace  is 

-  high-bandwidth  suspension  control  for  ground-based  flexible 
structure  experiment, 

-  lightweight  compliant  robot  joint  conuol, 

-  stabilization  of  head-up  display  mirror, 

-  gyro  equipment  conuol, 

-  setvohydraullcs  for  radar  systems, 

-  active  suspension, 

-  active  vibration  damping  of  flexible  suucturcs. 

Control  techniques  involved  range  from  simple  PID  control 
over  Iqg-type  state  controllers,  observers  and  Kalman-Filters  up 
to  robust  Hw  controllers.  Gam-scheduling,  selftuning,  and 
adaptive  control  can  also  easily  be  implemented  even  on  a 
fixed-point  DSP. 

Reference.'! 

/!/  Hanselmann,  H.  and  A  Schwane,  "The  Programming 
Language  DSPL",  Preprints/Proccedings  of  1990  Power  Con¬ 
version  and  Motion  Control  Conference  (PCIM),  Muntch,  June 
25-28. 

/2/ Hanselmann,  H.,  "Implementation  of  Digital  Controllers-  A 
Survey",  Automatica,  Vol,  23,  pp.  7-32,  January  1987. 

/3/TMS320C30  Optimtzing  C  Compiler  Reference  Guide, 
Texas  Instruments,  1990. 

/4/ Hanselmann,  H.,  "Low  Resolutton  Implementation  of 
High-Resolution  Positton  Control",  IEEE  Transactions  on 
Automatic  Control,  Vol  33,  No.  1 1,  pp.  1074-1078,  November 
1988. 

/5/ Hanselmann,  H.,  Henrichfreise,  H.,  Hostmann,  A„  and  A. 
Schwane,  "Hardware-in-the-Loop  Simulation  mit  Signal- 
prozessorsystemen”.  Preprints  Echlzeit'91  Conference 
(Rael-Time’91),  Sindelfingen,  June  11-13, 1991. 

Appendix 

Control  Implementation  Example 

A  motion  controller  for  an  electromechanical  actuator  is 
considered  (Fig.  9).  The  actuator  model  is  of  7th  order  due  to 
structural  mechanical  resonances  around  1,5  and  2  kHz.  The 
actuator’s  position  and  the  elecuical  driving  current  are  mea¬ 
sured  by  sensors. 


CONTROLLER 


Fig.  9:  controller  example 

The  Iqg-type  (linear-quadratic-gaussian)  controller  is  assumed 
to  be  designed  a:  a  linear  quadratic  optimal  (Iq)  state  feedback 
with  a  stationary  Kalman-Fiiter  as  an  observer.  The  design  has 
been  performed  with  MATLAB.  A  rate-limiter  will  be  added  in 
the  reference  path,  making  the  controller  nonlinear.  1  he 
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rate-limitcr  prevents  touching  signal  saturation  at  one  of  the 
sensors  and  thereby  greatly  improves  medium-to-large  signal 
behaviour. 

The  steps  are: 

(1)  Iqg  design  in  MATLAB 

The  sampling  rate  is  set  to  10  kHz.  First  results  within 
MATLAB  arc  the  state-feedback  vector  (including  the  refer¬ 
ence  feedforward  gain),  plus  the  constant  Kalman-Gain  matrix. 

From  the  state-feedback  and  Kalman-Filter  the  complete  con¬ 
troller  can  be  constructed  within  MATLAB,  written  to  disk, 
and  convened  into  a  format  expected  by  IMPEX.  An  alterna¬ 
tive  is  to  write  the  state-feedback  and  Kalman-Filter  to  disk 
separately,  convert  them,  and  then  use  IMPEX  for  combining 
these  into  one  single  controller  block. 


The  above  description  cames  all  information  on  the  controller 
dimension,  numerical  values  of  the  matrices  in  (1),  signal 
names  and  their  optional  ranges  and  units.  This  controller  has  a 
total  of  80  nonzero  coefficients,  49  in  i4, 21  m  fi,  7  in  C,  3  in  O. 

(3)  Application  of  IMPEX 

The  following  main  steps  are  performed: 

-  Structure  transformation,  reducing  the  number  of  coefficients 
inii  from  49  to  11. 

-  Automatic  state  scaling  for  fixed-point  implementation. 

-  Specification  of  i/o  for  code  generation. 

-  Specification  of  scalar  product  handling  as  to  be  realized  by 
DSPL  compiler. 

-  DSPL  source  code  generation. 


(2)  Create  basic  block  readable  by  IMPEX  (first  alcmativc, 
excerpt  only): 
basic  block  is 


—  file  C:\NICE\SEMC25\LQGDES\LINX.BBL 

—  20  Dec  90  1:30:54  pm 


samplingjperiod  l.OE-04; 


syatem^inputa  is 
name  ->  u^x^ref,  unit  ->  V, 
lowet_bound 
upper^bound 

name  ■>  u_x,  unit  ->  V/ 

lowec_^bound  -> 
upper^bound  -> 
name  ->  unit  •>  V, 

lower^bound  -> 
uppec^bound  -> 
end  syatem^inputa; 


->  -I  OE+01, 
->  l.OE+01; 

-1.0E^01, 

l.OE+01; 

•l.OE+01, 

l.OE+01; 


ayatem^^outputa  ia 

name  ->  u^M,  unit  •>  V, 

lowet^bound  «>  -l.OE+Ol# 
upper^bound  ->  l.OE+01; 

end  ayatem^outputa; 


ayatem_equations  aad  ia 

ayatem^repreaentation  :•  PHYSICAL; 
ayatem^atates  ia 
name  ->  xl; 
name  ->  x2; 


The  following  DSPL  program  is  produced  (excerpt  only): 

aeptype  atatel  ia  fix' (acculength  «>  32, 
round  ->  on, 
acale  •■>  on, 
aaturation  ->  off), 

aeptype  outl  la  fix' (acculength  ->  32, 
round  ->  on, 
acalc  ">  conanon, 
saturation  ••>  on)  ; 


xk  :  vector  (?)  of  fractional; 

xkl  :  vector  (7)  of  fractional; 

u  :  vector  (3)  of  fractional; 

input  is  u; 

y  :  vector  (1)  of  fractional; 

output  ia  y, 

temp)  :  rawaccumulator; 


begin 

©very  l.OE-04  do 
update  (xkl,  xk); 
input  (u) ; 

accumulate  preacalpro  (outl) 
yd)  tempi  +  dl  *  u; 
end  accumulate; 

output  (y);  --  line  152 

accumulate  acalpro  (atatel) 
xkld)  al  *  xk  i  bl  ‘  u; 
end  accumulate; 


name  ->  x7; 
end  syatem^statea; 
dynanic_matrlx  is 

a(  1,  1)  -5.13340T03582052E-01; 

2,  1)  ■-  4.15508858S06746E-05.  (4)  Compilation  and  download  (firsi  Without  rate-limiter) 


row_output_matrix  u^M  is 


c( 

1) 

-3.41575795865014E+01 

c( 

2) 

-1.73899220842727E+05 

c( 

3) 

-2.7246l533485298Ef0l 

c  ( 

D 

3.72279499287142E+05 

c< 

5) 

-3.05696777635724E+00 

c( 

6) 

-2  41915412951632Et05 

c( 

1) 

1.36757999529863E+00 

end  row_output_matrix; 
direct_link  u_x_ref  to  u^M  is 
d  1.42651871551162E+01; 
end  dircct_link; 
direct  link  u  x  to  u_M  is 
d  :-“-9.983363937l6665E+00, 
end  direct_^link; 
direct__link  u  I  to  u^M  as 
d  *-  -3.0473936899C223E-01. 
end  direct^link, 
end  systen^equations; 
end  basic_block; 


The  linear  controller’s  DSPL  code  is  fust  compiled  for  a  TMS 
320C25  second  generation  fixed-pomt  DSP,  the  assembly 
language  output  assembled,  and  the  object  file  loaded  onto  the 
hardware  if  it  is  attached.  All  that  can  be  done  by  invoking  just 
one  batch  file. 

Compilation  yields  the  following  processor  load  info  file, 
which  shows  that  at  maximum  27.6  ps  are  needed: 

execution  time  zequicementa 

task  I  cycles  )  rate  (kHz)  I  time  (us)  I  rqat  (us) 


II  276  I  36.232  |  27.600  I  100.000 

total  ptoceasot  load  27.60  \ 

303  words  of  code  (off-chip) . 

37  words  of  data  (on-chip) . 

32  words  stack  (on-chip) 
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An  excerpt  of  the  assembly  code  produced  highlights  the 
automatically  generated  comments  and  DSPL  statement-wise 
execution  cycle  profile  information.  Line  152  of  the  DSPL 
source  is  marked  in  the  above  DSPL  exceipt  for  reference. 


addh 

_cl5 

tovm 

;  disable  HW  satuc 

sfl 

;  rescale 

sach 

_v2,  7 

;  yd) 

— —  19  cycles 

line  152 

ds2101 

.  0,2,_v2,080h,2 

;  output  y(l) 

7  cycles 

line  153 

zac 

It 

v8 

;  xk(l) 

mpyk 

3172 

;  aid) 

Ita 

__v8+l 

;  x)c(2) 

mpy 

_c3 

;  aU2) 

Ita 

vl 

;  ud) 

mpy){ 

-76 

;  bUD 

Ita 

vl+1 

;  u(2) 

irpyk 

-3660 

;  bl(2) 

Ita 

vl+2 

;  u(3) 

mpyk 

-23 

;  bl{3) 

apac 

adlk 

1,  14  -  0 

;  perform  rounding 

;  no  oveiflow  teat,  roscaling  0  bit 


aach  _v5,  t  ,  xkltl) 

15  cyclea 


(,‘i)  Mcrging-in  the  rate-limiter  code 

The  following  file  inslmcis  MERGE  so  as  to  include  the 
rate-limiter  code: 

3  #bogin#  -  1  insert 

I 

r_la3t  :  fractional, 
delta  ■  fractional,, 

inax_delta  ;  constant  fractional  0.008;# 

0  lupdate#  +1  insert  #  r_la3t  u(i;;# 

0  #accuffiulate#  insert 

# . 

delta  utU-r^last, 
if  delta  >  max_delta  then 
u(l)  r_la3t  •  max_delta; 
elsif  -delta  >  ma^  elta  then 
u(l)  :•  r_la3t  -  max_delta; 
end  if; 

. - . ♦ 

The  first  line  of  this  merge  control  file  for  instance  contains  the 
following  merge  instructions;  look  for  the  string  ’begin’,  go  up 
one  line,  then  insen  the  3  lines  of  declarations  bracketed  in  by 
the  #  character.  One  executable  statement  and  a  sequence  of  6 
executable  statements  are  inserted  by  the  next  two  merge 
instructions. 

Invoking  MERGE  for  ihe  above  DSPL  source  and  merge 
control  file,  compiling,  assembling  and  download  can  again  all 
be  performed  by  just  invoking  one  batch  file. 

(6)  C  code  generation 

If  the  same  controller  is  to  be  implemented  on  the  TMS 
320C30  floating-point  DSP  C  c^e  generation  has  to  be 
selected  in  IMPEX.  The  same  MERGE  utility  can  then  be  used 


to  insert  the  rate-limiter.  An  excerpt  of  the  resulting  code  is 
shown  below; 

/*  declaration  of  input  /  output  functions  */ 

void  start  () ; 
float  dsZOOlO; 
void  ds2101(); 

/*  declaration  of  coefficients  */ 

/*  dynandc  matrix  */ 

float  al_l  -  9.6813219E-02; 

float  al“2  -  8.8771683E-01; 

I*  input  matrix  */ 

float  bl_l  -  -1.4816430E+00; 

/*  declaration  of  variables  */ 

/*  state  variables  */ 

float  xl_modal  -  O.OOOOOOOE+OO;, 
float  x)cl_l  -  O.OOOOOOOE+00; 


/*  input  Variables  *! 
float  u_x_ref^scaled  -  0 . OOOOOOOE’*-O0; 

float  u^x_scaled  -  0 . OOOOOOOE+00; 

float  u_I_3caled  -  O.OOOOOOOE+00; 

/*  output  variables 

float  u_M_scaled  -  O.OOOOOOOE-^OO;, 

/*  temporary  variables  */ 
float  temp^l  -  O.OOOOOOOE+OO;, 

/*---  rate  limiter 
float  r^last. 
float  delta, 

float  max_^delta  -  0.006; 
oxoc  time 

long  timer_^new,  tifrer_old; 

long  ‘timer^counter  ■  (long  •)  0x808034; 

float  exec_time; 

float  t_Clock  “  1.2012B-'7; 

c^intlOO 

( 

tiiner_old  ••  *timer_counter, 

asm("trapu  27");  /*  call  TRACB30  */ 

xl_^modal  •  xkl^^l; 

x2^moddl  •  x);l_2; 

x3_modal  -  xkl_3, 

x4_,modal  »  xkl_4; 

x5__modal  •  xkl__5; 

xS^modal  -  xkl_6; 

x7_^modal  "  xKl_7; 


/*— •  rate  limiter - »/ 

r^last  -  u_x_ref_scaled; 

/* . . . •/ 

start  (); 

u_x_ref_scaled  -  ds2001 (0x00000000,  0x00000001) 
/*...  rate  limiter - — 


delta  -  u_x__xef_scaied-r_^last; 
if  (delta  >  max^delta) 

u_x_cef__3caled  •  r_last  +  max^delta; 
else  if  ('delta  >  max_delta) 

u_x  ref_3caled  -  r__la3t  -  max_delta, 

— r. . ./ 

u_x__3caled  -  ds2001  (0x00000000,  0x00000002); 
u_I_3caled  -  d3200l (0x00000000,  0x00000003), 
u_M_3calcd  • 
teirp_l  + 

dl_l  *  u__x__ref_scaled  ♦ 
dl_2  *  u^x^scaled  r 
dl  3  *  u  I  scaled; 


da2101  (0x00000080,  0x00000001,  u_M_3caled) 
xlcl  1  - 


al  1 

* 

xl_modal  + 

a  1^2 

* 

x2__modal  + 

bl“l 

* 

u_^x__^r  e  f c  a  1  e  d 

+ 

bl  2 

* 

u_x_scaled  + 

bl  3 

* 

u__I__scaled; 

xkl  2  - 

a2_l 

* 

xl_modal  + 

a2  2 

* 

x2_modal  + 

b2  1 

* 

u_x^ref_8caled 

+ 

b2_2 

* 

u_x_3caled  + 

b2  3 

* 

u_l_^acaled; 

xkl  3  - 

a3  3 

* 

x3_modal  + 

a3_4 

* 

x4_Tnodal  + 

b3  1 

* 

u_x_^re£_3caled 

+ 

b3_2 

* 

u_x__3caled  + 

b3  3 

* 

u__I__3caled,‘ 

xkl  4  - 

a4_3 

x3_modal  + 

x4_modal  + 

b4_l 

u_x__ref_3caled 

+ 

b4_2 

u__x_^3caled  + 

b4  3 

u__I_3caled; 

xkl  5  - 

a5_5 

* 

xS^modal  + 

b5“l 

* 

u_x^ref_3cal©d 

+ 

b5“2 

* 

u_x_3calt>d  + 

b5_3 

* 

u^I^scaled, 

xkl  6  «■ 

a6_6 

* 

x6^modal  + 

b6*"l 

* 

u^x_ref^3caled 

+ 

b6“2 

* 

u__x^3Caled  + 

b6“3 

* 

u_I^3caled; 

xkl  7  - 

a7  7 

* 

x7_modal  + 

b7“l 

* 

u_x_ref_3caled 

+ 

b7“2 

* 

u^x_3caled  + 

* 

u^l^scaled, 

temp  1 

- 

cl"l 

* 

xkl_l  + 

cl“2 

* 

xkl“2  ► 

cO 

* 

xkl  3  + 

cl”4 

* 

xkl"4  + 

cl^S 

* 

xkl"5  ♦ 

cl  6 

• 

xkl“6  * 

cr7 

* 

xkl*‘7;, 

timer_new  -  *timer_counter; 

ex0C_tin>e  -  (tiin«r_new  -  timet  old)  *  t  cloc)t; 


The  C  code  as  generated  by  IMPEX  has  been  enhanced  via 
MERGE  with  some  code  for  execution  time  measurement  by 
TRACE. 

The  code  exhibits  indexless  (no-arrays)  calculation  for  maxi¬ 
mum  speed  The  dsXXXX  functions  are  t/o  functions  for  the 
specific  hardware. 


A  comparison  of  1st,  2nd  and  Jrd  generation  DSPs  executing 
the  above  conuoller  including  the  rate-limiter  programmed  (or 
better,  code  generated)  in  the  appropriate  language  is  given  in 
the  table  below.  The  execution  time  figures  are  exclusive  i/o, 
which  can  take  about  a  microsecond  with  the  right  penpher^l 
hardware  architecture  and  components 


processor 

language 

clock 

execution 

TMS  320C14 

DSPL 

25  MHz 

26  6  PS 

TMS  320C25 

DSPL 

40  MHz 

18.1  PS 

TMS  32(X:30 

C 

33  MHz 

“15  PS 
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ABSTRACT. 

Predictive  Functional  Control  (P.F.C.),  a  Mode  Eased  Predictive  Control  (MBPC)  technique  is  a  control  strategy  based  on  the 
use  of  a  model  to  predict  the  process  output  over  a  long  range  time  period.  This  technique,  fully  compatible  with  the  "CAD- 
based  integrated  design",  is  presented  here.  Tlie  link  between  the  specification  and  the  control  law  mning  parameters  is  made 
and  the  benefits  of  the  use  of  a  CAD  tool  is  demonstrated.  Two  industrial  applications  are  detained.  The  Erst  one  concerns  the 
guidance  law  of  an  air  defence  short  range  missile.  The  second  one  consists  in  the  control  of  the  two  axis  tunet  of  a  very  short 
range  air  defence  weapon  system. 


1.  INTRODUenON 

Design  of  control  laws  for  weapon  systems  are  subject  to 
more  and  more  severe  constraints.  These  laws  have  to  satisfy 
high  quality  performance  and  have  to  be  adapted  to  more  and 
more  difficult  environments  (inter-changeability  of  sensors 
and/or  actuators,  restricted  and/or  evolutive  specifications, 
processes  with  unusual  behavior  delay,  non-minimum 
phase,  non-linear,  non-stationary,  oscillatory,  unstable, 
...etc).  In  these  conditions,  tight  correlation  between  the 
parameters  to  be  tuned  and  the  required  specifications  have  to 
be  established  in  order  to  allow  rapid  prototyping.  A  good 
pcrformance/cost  ratio  is  thus  necessary. 

Predictive  Functional  Control  (PFC)  technique  presents 
interestmg  characteristics  for  this  purpose.  PFC  is  a  model 
based  predictive  control  technique  developed  by  ADERSA 
and  used  by  THOMSON-CSF  in  the  last  few  years.  The 
control  is  designed  according  to  a  receding  horizon  strategy, 
using  explicitly  a  model  to  predict  the  process  output  over  a 
long-range  time  period.  For  linear  models,  this  leads 
analyt'cally  to  a  linear  regulator  which  can  be  easily 
implemented  in  an  on-board  computer  fo:  real-time 
applications. 

The  technical  features  of  PFC  are  well  appreciated  :  follow-up 
servo  performances,  robustness,  simple  constraints 
handling,  possibility  of  controlling  difficult  processes, 
compensation  of  measured  disturbances  by  a  feedforward 
action,  inherent  dead-time  compensation,  ....  But  the  most 
appreciated  characteristic  is  its  ease  of  tuning  ;  in  fact  PFC 
design  introduces  specification  parameters  rather  than  tuning 
parameters  this  allowing  direct  relation  with  performance. 
This  main  feature  makes  the  PFC  technique  fully  compatible 
with  the  "CAD-based  integrated  design"  and  "engineering 
workstation"  concepts. 

PFC  environment  permits  acceleration  of  the  phase  between 
model  identification  and  performance  evaluation.  Once  the 
model  is  obtained,  the  control  strategy  is  straight-forward  by 
defining  the  setpoints  nature  and  the  required  specifications. 
In  the  PFC  software,  many  procedures  are  dedicated  to  assist 
the  user  in  the  parameters  selection  in  relation  with  the 
specifications.  Simulation  and  behavior  analysis  (in  both 
lime  and  frequency  domains)  of  the  process  controlled  by 
PFC  can  also  be  accomplished  by  the  software. 

An  expert  system  has  been  added  by  THOMSON-CSF  to  the 
PFC  software  in  order  to  save  experience  of  existing  PFC 
users  and  to  help  for  rapid  training  of  new  personal.  The  PFC 
concepts  can  thus  be  mastered  in  a  short  time  ;  this  is 


particularly  allractive  for  non-expert  technical  persons  who 
have  a  limited  control  background. 

All  the  tools  associated  with  the  PFC  software  increase 
considerably  the  interest  in  the  technique.  PFC  is  wide-open 
to  further  extensions. 

The  main  characteristics  of  the  PFC  software  are  given  in 
section  2. 

In  the  fields  of  air  defence  systems,  in  which  we  apply  it, 
this  technique  present  moreover  the  advantage,  with  regard 
to  conventional  techniques,  to  propose  a  package  r 

•  complete  for  the  computation  of  the  control  (it 
includes  both  feedback  and  feedforward  actions  in  the 
case  of  unknown  setpoint), 

-  independent  in  the  case  of  temporary  lack  of  measures 
(setpoint  or  output  process). 

This  technique  has  been  used  by  THOMSON-CSF  mainly  in 
the  following  two  applications  : 

-  in  simulation  (engineering  simulator  of  short-range 
weapon  system)  for  all  phases  of  line-of-sight 
guidance  (initial,  pursuit  and  terminal)  of  a  high 
velocity  missile.  The  missile  characteristics  are  ; 
non-stationary,  non-linear  and  non-minimum  phase. 
This  technique  has  proved  to  be  very  performant  with 
regard  to  a  classic  law  (adaptative  PID)  in  the  case  of 
fast  manoeuvring  targets  (aircraft  evasive 
manoeuvres,  missile  and  aircraft  helicoidal 
manoeuvres)  and  it  maintains  very  good 
performances  in  the  case  of  straight  targets,  radial  or 
not. 

-  in  simulation  and  on  the  actual  weapon  system  for  the 
turret  homing  to  target  phase  of  a  very  short  range 
weapon  system,  This  turret  presents  many  non- 
linearities  such  as  friction,  free  motion,  hysteresis 
and  saturation.  Its  behavior  depends  on  the  amplitude 
of  the  effective  movement.  The  PFC  technique  with 
its  associated  CAD  tool,  allowed,  not  only  to 
improve  the  dynamic  performance  with  regard  to 
polynomials  regulators  (previously  used)  but  also 
rejects  the  effect  of  perturbations  such  as  blast  of 
wind,  noises  and  inertia  variations.  The  looked  for 
robustness  was  not,  in  the  past,  achieved  by  other 
technique. 
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These  iwo  applications  are  treated  in  section  3. 

2.  PFC  SOFTWARE 

The  general  principles  of  the  PFC  technique  are  briefly 
presented  here,  in  the  .single  input  -  single  output  case,  then 
the  main  characteristics  of  tite  software  arc  described  and  its 
CAD-compatible  nature  is  shown.  Details  on  the  PFC 
algorithm  which  leads  to  a  linear  control  expression  are 
provided  in  the  Appendix  A. 


2.1.  PFC  GENERAL  PRINCIPLES 

PFC  is  a  particular  long-range  predictive  control  technique. 

The  control  variable  is  calculated  on-line  according  to  the 

following  receding  horizon  strategy. 

At  each  sampling  time  (Figure  1) 

-  the  process  output  has  to  rally  a  setpoint  trajectory  in 
the  future. 

-  a  reference  trajectory  initialized  on  the  actual  process 
output  defines  the  way  to  follow  the  setpoint  on  a 
prediction  horizon  ;  the  characteristics  of  this 
trajectory  are  chosen  in  relation  to  the  desired  closed- 
loop  dynamics.  A  first  order  decay  error  between  the 
seipoint  and  the  process  output  is  generally  used. 


past  —  present  — ►  future 


Tlie  future  control  variable  is  structured  as  a  linear 
combination  of  a  pre-specified  set  of  functions  called 
base  functions.  The  choice  of  these  functions  depends 
on  the  nature  of  the  process  and  the  setpoint. 
Gcrerally  step,  ramp,  parabola,  ...  are  used. 

The  process  model  allows  expression  of  the  output 
prediction  under  the  effect  of  the  future  control 
sequence.  The  process  output  prediction  is  then 
adjusted  by  talcing  into  account  the  extrapolated 
distance  (in  the  future)  between  the  process  and  model 
outputs  based  on  past  observation.  This  is  called  the 
self-compensation  pr<x:edure. 

The  control  objective  is  to  minimize  the  sum  of  the 
squared  errors  between  the  predicted  output  and  the 
reference  trajectory  at  certain  points  of  the  prediction 
horizon  call^  the  coincidence  points.  The  number  of 
these  points  is  at  least  equal  to  that  of  the  base 
functions.  Adding  a  quadratic  term  in  the  control 
variable  or  its  variations  to  this  criterion  allows 
control  smoothing. 


-  The  control  variable  computation  consists  of 
determining  the  unknown  coefficients  of  the  linear 
combination  of  the  control  expression.  Only  the  first 
value  of  the  future  control  sequence  is  used  to  control 
the  process.  The  whole  proc^ure  is  repeated  at  the 
next  sampling  instant  and  so  on. 


2.2.  PFC  PARAMETER-S  AND  THEIR  PERFORMANCE 
RELATION 

It  is  assumed  here  that  the  reader  is  already  acquainted  with 
the  Appendix  I  in  which  details  on  the  PFC  algorithm  are 
given.  We  first  present  the  list  of  the  PFC  tuning  parameters 
and  then  we  indicate  how  they  can  be  selected. 

The  parameters  are  of  two  types  :  basic  and  optional  :• 

-  basic  parameters,  these  are  :■ 

the  base  functions 

the  reference  trajectory  (response  umc) 
the  coincidence  points 

The  influence  of  these  basic  parameters  on  the  main 
specifications  is  illustrated  in  the  following  table 
where  0,1  and  2  mean  weak,  medium  and  high 
influence  respectively 


Tuning 

Specification 

Base 

functions 

Reference 

trajectory 

Coincidence 

points 

Steady-state 

accuracy 

2 

0 

0 

Closed-loop 

dynamics 

0 

2 

1 

Stability  - 
robustness 

0 

1 

2 

The  almost  diagonal  property  of  this  matrix  shows 
that  the  basic  parameters  are  specifications  parameter 
directly  connected  to  the  performance  characteristics. 


Optional  parameters,  these  arc  for  ; 

self-compensation  (extrapolation  polynomial 
degree,  number  of  past  observations  and  their 
filtering) 

setpoint  extrapolation  (degree  of  the  polynomial, 
number  of  past  values) 

.  criterion  modification  (weight  of  the  quadratic 
term  added  and  order  of  the  control  variable 
variation  considered) 

Concerning  the  influence  of  these  optional 
parameters,  we  can  give  the  following  elements. 

The  self-compensation  procedure  is  necessary  when 
the  difference  between  the  process  and  model  output 
causes  a  not  constant  asymptotic  tracking  error  if  no 
self-compensation  is  used. 

The  seipoint  extrapolation  in  a  polynomial  form 
ensures  the  steady-state  accuracy  when  the  setpoint  is 
not  known  in  the  future. 
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The  criterion  modiHcstion  is  intented  to  produce  a 
more  regular  control.  It  is  particularly  interesting  in 
the  presence  of  noise. 


2.3.  TUNING 

For  some  of  the  already  listed  PFC  parameters  the 
specifications  can  guide  their  selection,  this  is  the  case  of 
the  time  response  of  the  reference  trajectory  and  the  setpoint 
extrapolation  degree. 

For  some  others,  rules  derived  from  theoretical  results  have 
to  be  applied  ;  this  is  the  case  for  the  choice  of  the  base 
functions. 

Unfortunately,  for  the  remaining  parameters,  there  is  no 
straight  forward  link  between  them  and  the  performance 
characteristics.  Thus  for  the  selection  of  these  parameters, 
no  rules  exist  apart  from  some  elementary  ones.  For  these 
parameters  the  software  PFC  provides  many  help  procedures 
to  the  user,  through  specific  experimental  results  giving,  for 
different  choices  of  the  parameters,  many  performance 
criteria  (closed  loop  dynamics  and  robustness  margins,  ...). 

The  limited  scope  of  the  paper  does  not  allow  to  give  alt  the 
details  concerning  the  tuning  of  each  parameters. 

Gut  one  can  be  said  is  that  the  possibilities  o.'  ered  by  the 
PFC  software  permits  easy  tuning  and  rapid  prototyping. 
PFC  can  be  used  by  non-experts,  it  is  a  good  candidate  for 
CAD-based  Integrated  Design. 


2.4.  TUNING  WITH  AN  EXPERT  SYSTEM 

An  expert  system,  called  PFC-EXPERT,  has  been  built  from 
KIRK  (developed  by  THOMSON-CSF).  KIRK  is  an  expert 
system  shell.  Its  principal  functionalities  are  a  forward 
chaining  capability,  a  prolog-based  backward  chaining 
capac'iity,  packet  of  niles  to  organize  the  knowledge  base. 

The  PFC-EXPERT  knowledge  base  contains  the  tunmg  rules 
related  to  basic  parameters  (see  section  2.3).  In  the  case  of 
optional  parameter,  the  rules  are  defined  from  experience  of 
existing  PFC  users  acquired  by  interpretation  of  performance 
criteria  pr.ovided  by  the  software  PFC. 

The  PFC-EXPERT  presente  advantages  to  accumulate  the 
knowledge  of  the  users  and  to  help  for  rapid  training  of  new 
personal. 


3.  APPUCATIONS 

3.1.  MISSILE  GUIDANCE 

3.1.1.  PROBLEM  STATEMENT 

Interception  of  a  moving  target  (aircraft  or  missile)  by  a 
remote  control  missile,  launched  from  a  fixed  or  moving 
platform,  is  a  complex  dynamic  problem  composed  of 
several  phases.  Once  the  target  is  detected,  the  launching 
platform  is  oriented  such  that  initial  conditions  of  the 
missile  flight  are  the  most  favorable.  Simultaneously,  the 
weapon  system  computer  estimates  the  most  appropriate 
time  to  launch  the  missile.  As  soon  as  the  missile  is 
launched,  it  is  guided  until  the  interception  of  the  target.  In 
the  domain  of  short-range  weapon  systems,  the  type  of 
missile  guidance  is  generally  a  L.O.S.  guidance  (Line  of 
Sight). 

The  L.O.S.  concept  ban  be  characterized  by  three  points  :  the 
position  of  the  fire  unit,  of  the  target  and  of  the  missile.  The 
object  of  the  L.O.S.  guidance  system  is  to  constrain  the 


missile  to  lie  as  nearly  as  possible  on  the  line  joining  the 
fire  unit  and  the  target  called  the  line  of  sight. 

The  concept  of  THOMSON-CSF  L.O.S.  systems  is  automatic 
using  differential  missile  to  target  tracker  (ex.  CROTALE 
system)  where  all  the  operations  are  executed  at  ground  level 
to  correct  imperfect  target  tracking  in  the  guidance  loop. 


FIGURE  2  :  Principle  of  the  LOS  command 

The  main  research  works  on  the  missile  guidance  subject  [2], 
[3],  [4]  concern  the  "terminal"  phase  (see  figure  2)  buause  it 
is  a  deciding  factor  in  the  presence  of  targets  manoeuvres, 
particularly  during  the  hundredths  of  second  preceding  the 
interception.  Nevertheles.s,  each  phase  of  the  missile 
trajectory  has  a  different  objective  which  leads  to  the  success 
of  the  Tire.  The  First  phase  is  intented  to  counter  die  launch 
disturbances.  The  second  phase  objective  is  to  minimize  the 
energy  consumption  to  preserve  a  high  potential  of 
manoeuvrability.  Finally  the  "terminal"  phase  is  concerned 
with  the  miss  distance  minimization.  Generally,  there  exists 
a  guidance  law  structure  adapted  to  each  phase  and  an 
appropriate  methodology  for  tuning  the  parameters  of  each 
guidance  law. 

In  the  most  general  case,  the  inputs  of  the  guidance  law  are 
(see  Figure  3  ) ; 

-  eim,  measures  of  the  metric  differential  gap  target  to 
missile, 

-  6(  et  ddg/dl  measures  of  position  and  speed  binded  to 
the  line  of  sight  motion, 

-  rni,  estimated  value  of  Fue  unit  to  missile  range. 

The  acceleration  Fg  (see  Figure  3)  is  the  output  of  the  control 
computer  and  is  calculated  in  the  missile  reference  system  of 
coordinates. 

The  specifications  required  for  the  guidance  law  are  : 

-  to  minimize  the  error  Cmi  at  the  interception, 
particularly  in  the  case  of  fast  manoeuvring  targets, 

-  to  minimize  the  noises  on  the  missile  control 
acccK.ations, 

-  robustness  with  respect  to  the  inaccurate  knowledge 
of  the  process  (non  stationary,  non  linear,  non¬ 
minimum  phase,  reference  system  change,  ...etc). 


18-5 


3.1.2.  CCTITRCX- LAW  DETERMlNA'nCW  WITH  CAD 
TOCXS 

The  following  elements  are  needed  for  the  predictive 
guidance  law : 

the  calculation  of  the  future  setpoint  trajectory.  The 
more  convenient  way  to  do  that,  is  to  extrapolate 
filtered  past  values  in  a  fixed  reference  system, 

.  the  calculation  of  the  position  of  the  nussile  in  the 
selected  reference  system  axes.  It  can  be  easily 
reconstructed  from  the  mesured  error  emr  and  the 
estimated  setpoint  (see  figure  4  below), 

a  linear  model  that  gives  the  realized  position  of  the 
nussile  from  any  control  acceleration. 


FIGURE  4  ;  Struemre  of  the  predictive  guidance  law 

The  single  input  -  single  output  PFC  control  law  elements  are 
described  in  figure  5  : 

Where  :  n  =  current  time, 

itg  -  lime  ts  go,  estimation  of  the 

remaining  lime  before  intercep¬ 
tion, 

tmd  =  output  of  a  target  manoeuvre 
detector. 

The  internal  model  chosen  is  relatively  simple  in 
comparison  with  the  process  complexity  and  does  not  result 
from  a  very  accurate  identification  proc^urc.  It  consists  in  a 
transfer  function  which  represents  very  approximalively  the 
missile  for  a  given  flighl  time,  a  total  lime  delay  in  the 
guidance  loop  and  a  double  integration.  The  parameters  arc 
considered  time  invariant. 

In  what  follows,  two  PFC  laws  are  described  by  mean  of  the 
same  set  of  equation.  "PFC  Icrminal"  includes  a  terminal 
phase  with  the  lime  to  go  estimation  t(g  and  "PFC"  is  the 
same  with  l|g  =  0  assumption.  The  passing  over  from  "PFC" 
law  to  "PFC  terminal"  law  is  very  easy. 


The  principle  of  "PFC  terminal"  law  is  to  vary 
simultaneously  the  coefficients  (ki(i=0,l,2),  v)  of  the  PFC 
regulator  in  function  of  two  variables  :  the  output  tmd  of  the 
target  manoeuvre  detector  and  the  estimation  of  the 
remaining  lime  before  the  interception  (t|g).  This  leads  to 
the  following  regulator  equation  :■ 

r(n)  =  koftmd,  ttg).(co(n)  -  yp(n))  + 

2 

I[ki(tmd.  t,g).(ci(n)  -  e,(n))]  + 
i=l 

v'^'flmd.  itg).XM(n) 

The  evolution  expressions  for  coefficients  k;  and  v  are  given 
by;. 

ki  =  k,_init  *  (a;  -  bj’tmd)  *  evk;  for  i  =  0,  1,  2 

''  =  vini,  •  (aj  -  bi*tmd)  *  evk] 

where : 

-  aj,  bj  and  evkf  are  positive, 

-  the  values  kjjnit  (>  =  ^  2)  and  vj;,jt  arc  those 

corresponding  to  a  tuning  which  requires  a  weak 
dynamics  (i.e.  that  the  coincidence  points  are  nearly 
of  the  reponse  lime). 

-  for  Und  :■  a  law  value  is  adapted  to  helicoidal  and 
evasive  manoeuvres  requirmg  strong  dynamics,  a 
high  value  is  adapted  to  defiling  targets  which  need 
medium  dynamics. 

-  evkj  =  1.-8  eki’evk  for  i  =  0,  1,  2  where  evk  is  a 
limited  function  of  I/t|g. 

The  numerical  values  of  ai,  b,,  vkj  for  i  =  0,  1 ,  2  result,  with 
the  PFC  software,  from  analyzing  the  evolution  of  ihe 
coefficients  kj  (i  =  0,  1,  2)  and  v  when  the  coincidence 
points  are  chosen  smaller  and  smaller.  The  PFC  software 
offers  very  great  facilities  for  that.  These  variations  arc 
linear  functions  of  tmd  and  t|g. 

3.1.3.  PERFORMANCES  COMPARISONS 

The  6  DOF  (degree  of  freedom)  simulator  used  U>  evaluate  the 
performances  of  the  different  guidance  laws,  is  representative 
of  an  existing  short-range  weapon  system.  It  encloses  an 
accurate  modelisation  (physical  models)  of  each  of  its 
material  components.  The  on-line  software  simulation  of  the 
weapon  system  is  according  with  the  real  time 
implementation.  The  conditions  in  which  the  guidance  laws 
have  been  tested  arc  thus  among  Ihe  more  realistic  ones. 

The  fire  topics  are 

-  Kl  }  aircraft  target,  radial  straight  target,  constant 

speed  =  .500  m/s,  interception  range  =  6.5  km, 

-  HI  :  aircraft  target,  helicoidal  manoeuvring  target. 

constant  speed  =  300  m/s.  around  A  parallel  to  X 
with  a  500  m  cross  range,  interception 
range  =  7.4  km 

-  H2  :>  same  as  HI  with  missile  target  and  constant 

speetl  =  160  m/s 

-  01  :  aircraft  target,  straight  and  level  a  long  A 

altitude  =  1000  m,  horizontal  cross  range  =  4500 
m,  constant  speed  =  350  m/s,  interception 
range  =  4600  m. 

-  D2  ;  same  as  D1  with  constant  speed  =  500  m/s,  A 

altitude  =  200  m,  cross  range  =  3000  m, 
interception  range  =  4200  m 
■  El  :  aircraft  target,  straight  horizontal  target, 
constant  speed  =  500  m/s,  e.scape  manoeuvre  5  g 
before  interception  range  5  km. 

-  E2  :  same  as  El  with  10  g  manoeuvre. 


FIGURE  5:  PFC  law 
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In  what  follows,  we  present  synthetic  results  of  the  Monte- 
Carlo  simulations  for  the  different  laws  evaluated  ; 
"classical"  law  ("PIO"  type  adaptative  regulator  with 
feedforward  action),  "PFC"  law  and  "PFC  terminal"  law. 


lUal-umc  coAt^ct 


FIGURE  8  :  Funetional  scheme  of  the  turret  control 


The  system  includes  electromechanical  structures  and 
electronic  parts.  It  can  be  represented  by  a  three  dumb-bells 
model.  The  main  mechanical  components  of  the  chain  are  the 
motor,  the  gear  box  assembly  and  the  load.  The  chain 
caractcristics  are  ;• 

-  the  motor,  gear  box  assembly  and  load  inertias 

-  the  flexibility  and  the  damping  of  the  transmission 
gear 

-  the  free  motions,  fnctions  and  hysteresis 

•  the  gear  ratio 


FIGURE  6  ;  Guidance  taws  comparisons 


Electronic  loop  arc  mcluded  in  the  turret  assembly  hardware  ; 


The  superiority  of  the  predictive  guidance  law  is  obvious  in  -  regulation  loop  for  the  mo>or  current 

the  case  of  fast  manoeuvring  targets.  It  is  clear  that  the  -  tachometer  loop  for  regulation  of  the  motor  speed 

adding  of  a  terminal  phase  improves  the  performances  in 

term  of  miss  distance  from  30  to  60  %.  For  the  last  laws  and  Synchro-resolvers  give  the  angular  positions  (elevation  and 

from  a  real  time  point  of  view,  realistic  estimations  of  the  bearing)  of  the  load  compared  with  the  platform, 

duration  demonstrate  the  compliance  with  the  on  board 
computer  constraints. 


3.2.  TOW  AXIS  TURRET  CONTROL 


3.2.1.  PROBLEM  PRESENTATION 


The  objet  of  this  application  is  to  realize  the  control,  using  a 
real  time  computer,  of  a  two  axis  (elevation  and  bearing) 
turret.  The  system  allows  the  angular  tracking  of  a 
manoeuvring  aerial  target. 


FIGURE  9  :  Turret  assembly  (one  axis) 

The  control  variable  of  the  turret  assembly  chain  is 
representative  of  the  load  speed.  The  process  output  are  tite 
angular  positions  of  the  load  which  represent  the  line  of 
sight  for  the  tracking. 

Now  let  us  talk  about  constraints  and  required  performances. 

The  most  important  constraint  is  that  the  control  law  has  to 
withstand  : 

-  large  system  parameters  variations  (for  example  :  the 
range  of  the  turret  inertia  is  from  60  to  120  kg.m^). 
These  variations  have  an  effect  on  the  process  time 
response  (30  %)  and  on  the  process  lime  delay  (50  %) 


•  non  linear  effects  due  to  friction,  threshold, 
backlash... 


For  a  tracked  flying  target,  the  set  point  trajectories  are 
unknown.  Nevertheless,  most  of  them  correspond  to  a 
reclilmear  uniform  flight  at  a  constant  altitude.  The  involved 
setpoints  are  made  of  reversed  trigonometric  functions  (see 
figure  10)  :■ 
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For  example  :  0  =  arctg  — 

where  V  is  ihe  target  speed 

d  is  the  crossing  range 
t  is  the  current  time 


Morever,  the  turring  parameters  are  the  system  required 
specifications.  This  feature  makes  the  PFC  (the  choosen 
MBPC)  technique  fully  compatible  with  the  "CAD  based 
integrated  design”  and  “engineering  workstation"  concepts. 


0  is  the  bearing  scqmint 


The  allowed  tracking  error  in  the  previous  conditions  should 
not  exceed  5  mrad  with  a  rallying  time  response  as  shorter  as 
possible. 

In  order  to  preserve  the  electromechanical  parts.  Ihe  control 
is  subject  to  Ihe  following  constraints  ; 

I  “  linax  S  1.5  rad/s  and  |  *^  |  5  1.6  rad/s^ 

max 

As  the  real  time  computer  is  not  only  dedicated  to  the  tunet 
control,  the  sampling  time  cannot  be  less  than  20  ms,  which 
is  a  severe  restriction  according  to  the  system  time  response 

As  all  these  constraints  and  required  performances  are  very 
strict,  a  conventionnal  control  law  (Signal  Based  Control 
like  P.I.D.)  has  revealed  itself  quite  insufficient  because  :• 

■  the  set  points  to  follow  without  packing  error  look 
like  second  order  polynomials, 
die  control  variable  constramts  are  very  smet  and  are 
often  hit  (the  model  evolves  with  constrained 
control), 

-  die  sampling  time  (20  ms)  is  very  important  with 
respect  to  the  process  tune  response  (35  ms). 

-  the  process  is  highly  non  linear  (friction  is  an 
important  constraint)  and  a  SBC  conuol  law  would 
not  achieve  the  required  robusmess  performances. 

A  more  elaborate  conPol  law  is  needed.  Among  the  Model 
Based  Control  techniques,  the  Predictive  ones  (MBPC)  arc 
particularly  well  adapted  to  high  evolutive  setpoints. 


All  the  PFC  parameters  arc  listed  in  section  2.2.  For  same  of 
them,  the  specincaliuns  can  actually  guide  their  selection. 
For  example,  the  setpoint  exPapolalor  degree  is  linked  to 
the  typical  observed  setpoints  most  of  which  can  be 
approximated  by  second  order  polynomials. 

The  time  response  of  the  reference  trajectory  is  related  to  the 
process  response.  As  the  control  law  and  its  gradient  are 
limited,  the  lime  response  of  the  reference  trajectory  depends 
on  the  difference  between  the  setpoint  and  the  process  output 
which  IS  to  be  compensated.  Then  this  PFC  parameter  has 
been  tabulated  according  to  the  error  to  compensate. 

>r  =  f(c.  Sp) 

Others  parameters  tuning  derives  from  theoretical  results.  It 
IS  the  case  for  the  number  of  base  functions.  If  d  is  the  degree 
of  the  polynomial  setpoints  and  nj  is  the  number  of 
integrators  in  the  process  to  control  then  the  number  of  base 
functions  is  d  -  n;  +  1  if  the  specification  is  to  have  no 
tracking  error.  For  this  application,  as  the  process  is  once 
integrative  and  as  typical  setpoints  look  like  second  order 
polynomials,  two  base  functions  were  chosen  ;  the  step  and 
the  ramp. 

For  an  equation  system  lesolution  reason,  the  number  of 
coincidence  points  must  at  least  be  equal  to  the  number  of 
base  functions.  If  it  is  greater,  the  system  is  solved  with  a 
least  square  method.  Their  positionning  depends  on  Ihe 
desired  robustness.  It  also  has  some  effect  on  Ihe  control 
dynamics.  Situated  near  the  current  instant,  Ihe  band  pass  is 
large,  far  away,  the  dynamic  is  quite  poor. 
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Unfortunatly  neither  process  behaviour  specifications  not 
theoretical  results  can  be  a  way  to  determine  the  number  of 
comcidence  points  and  their  location. 

Here  is  one  of  the  main  interest  of  the  CAD  tool.  As  soon  as 
the  reference  trajectory,  the  base  functions  and  the  number  of 
coincidence  points  are  chosen,  an  on-line  help  gives  to  the 
user  the  gam  margin,  the  delay  margin  and  the  time  response 
for  different  locations  of  coincidence  points.  Results  are 
presented  in  a  table  in  which  the  user  can  choose  a  tuning  for 
the  cobcidence  points.  An  example  of  one  of  these  on-line 
help  tables  is  given  hereafter  (figure  11)  for  a  first  order 
reference  trajectory  (tj  =  0,1  s),  two  base  functions  and  two 
coincidences  points. 


NO  1 

points  coincld«ncft 

kO 

r«tsrd|tp*.  rep.* 

1 

0  0<iQO 

0  1000 

45. 3 

1 

6  Oi 

0  06001  0  120* 

21 

0  C600 

0.1000 

33  4 

1 

6.61 

0  06001  0  140* 

31 

0  0800 

0.1000 

27,7 

1 

7.41 

O.OeOOl  0  140* 

i\ 

0  0400 

0  0800 

47.2 

1 

5.81 

0.0600J  0.120* 

51 

0  0600 

0  0800 

36  1 

1 

6  61 

0  06001  0  120* 

61 

0.0400 

0.0600 

so  5 

1 

5  61 

0.06001  0  120* 

FIGURE  11  :  Example  of  coincidence  points  on-line  help 
results 

As  already  told  above,  most  of  the  setpoints  can  be 
considered  as  portions  of  second  order  polynomial.  This 
gives  the  degree  of  the  setpoint  extrapolating  polynomial. 
The  number  of  past  setpoints  values  used  in  the 
extrapolation  results  from  a  trade-off  between  the  following 
considerations 

The  noise  in  the  setpoint  is  quite  important  (o  =  25 
mrad).  Considering  a  great  past  horizon  wilt  have  a 
filtenng  and  delay  effect. 

10  %  of  the  setpoints  correspond  to  very  high 
evolutive  targets.  If  the  filtering  effect  is  important, 
the  extrapolation  will  be  bad  and  will  lead  to  the  loss 
of  the  tracked  target. 

All  the  MBPC  techniques  use  an  internal  and  linear  model  of 
the  process.  His  goal  is  to  predict  die  process  behaviour  in 
die  future  Unfortunately,  the  model  and  the  process  cannot 
be  identical.  The  model  only  approximates  the  process.  Its 
determination  results  from  a  global  identification  step  based 
on  datas  meseared  on  the  real  process  to  control.  The  chosen 
models  for  this  application  are 

HbM(s)  =  s  (1  -i- 0.03s) 

Hem(s)  =  5  (i";  0  024s)  for  elevation  axis 

As  the  process  and  the  model  are  not  identical,  the  process 
output  prediction  for  the  future  instants  will  be  bias^.  The 
process  and  model  mismatch  is  known  m  the  past  and  at  the 
current  instant.  It  can  be  then  extrapolated  in  the  future,  that 
is  the  purpose  of  the  self-compensator  which  parameters  to 
tune  are  ;■ 

-  degree  of  the  extrapolating  polynomial 
number  of  past  values  used  in  the  extrapolation 

-  time  response  of  the  process-model  mismatch  filter 


The  filter  is  necessary  to  smooth  the  extrapolated  datas 
because  of  the  noise  they  carry  with  them. 

For  the  tuning  of  these  parameters,  the  CAD  tool  gives  an 
on-lme  help  similar  to  the  above  one.  Once  given  the  degree 
of  the  extrapolating  polynomial,  the  user  gets  a  table  in 
which  are  given  the  gain  margin,  the  delay  margin  and  the 
time  response  for  several  values  of  the  filter  time  response 
and  the  number  of  past  values  used  in  the  extrapolation.  A 
particular  tuning  can  then  easily  be  chosen.  An  example  of 
this  on-line  help  is  given  below  (figure  12)  for  a  first  order 
extrapolating  polynomial. 


•No| 

nb.dotn  | 

tps.filtre  1 

n  gsln  | 

m  retsrd 

tps.  rep.  • 

•  11 

2  1 

0  100  1 

3  0  1 

0.0200 

0  120  * 

•  2l 

2  1 

0  200  1 

3.8  1 

0.0200 

0.120  • 

•  3l 

2  1 

0.500  1 

4  8  1 

0  0400 

0.120  * 

•  41 

2  1 

1  000  1 

5.2  1 

0.0400 

0  120  * 

•  SI 

5  1 

0.100  1 

5.0  1 

0  0200 

0  120  • 

•  6} 

5  i 

0.200  I 

5  4  1 

0  0200 

0  120  • 

•  7| 

5  1 

0  500  1 

5  6  1 

0.0400 

0.120  • 

•  81 

S  1 

1  000  1 

5  8  1 

0.0400 

0  120  • 

•  91 

10  1 

O.lOO  1 

5  8  1 

0  0400 

0  120  * 

•101 

10  1 

0.200  1 

5  8  ) 

0  0400 

0  120  • 

•111 

10  1 

0  500  1 

5  8  1 

0.0600 

0  120  • 

•121 

10  1 

1  000  1 

5  8  1 

0  0600 

0  120  » 

■Ul 

20  1 

O.IOC  1 

5  8  1 

0  0800 

0.120  • 

*141 

20  1 

0  200  1 

5  8  ! 

0.0800 

0  120  * 

•Ul 

20  1 

0  500  1 

S  8  1 

0  0600 

0.120  • 

•161 

20  1 

1.000  1 

5.8  1 

0.0600 

0  120  * 

FIGURE  12  :  Example  of  self-compensaior  on-line  help 
results 

To  tune  all  these  parameters  usmg  the  CAD,  several  steps  are 
necessary. 

.  Process  and  model  arc  identical,  control  variable  is 
not  constrained.  Reference  trajectory,  base  functions, 
coincidence  points  and  setpoint  extrapolation  must 
be  chosen. 

Process  and  model  remain  identical,  control  variable 
is  constrained.  Reference  trajectory  is  then  adjusted 
according  to  the  deviation  to  compensate. 

Process  and  model  are  different,  control  variable  is 
constrained  Choose  the  self-compensator 
parameters. 

During  all  the  procedure,  the  CAD  tool  can  generate  tlie 
behaviour  of  the  different  interesting  datas  showing  them  on 
time  depending  graphics 

Setpoint 

.  Control  variable 
Process  output 
Model  output 

Difference  between  setpoint  and  process  output 
Difference  between  process  and  model  outputs 


For  the  tracking  turret  application,  the  selected  parameters 
are 

•  First  order  trajectory  :■  tj  =  f  (c,  Sp) 

-  Two  base  functions  ■  step  and  ramp 

-  Two  comcidence  points  :  tj  =  0.04  s  t2  =  0.08  s 

-  Second  order  setpoint  extrapolator  with  5  past  values 
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-  First  order  self-compensitor  extrapolitor  with  10 
past  values 

-  Self-compensator  time  response  filter  =  O.S  s 

The  control  law,  written  in  ADA,  is  the  following  one. 

u(n)  =  Ico.(c(n),  Sp(n)).[co(n)  -  Sp(n)]  + 

T 

lci.fci(n)  -  di(n)]  -^k2.C2(n)■^■VJ^.XM(n) 

Where  :• 

n  is  the  current  instant 

c  IS  the  setpoint 

Sp  is  the  process  output 

Cj(n)  are  the  setpoint  polynomial  extrapolator 
d 

constants  such  as  c(n-(-l)  =  ^  Cj(n).ij 
j=0 

di(n)  is  the  first  order  constant  of  the  difference 
between  process  and  model  outputs  polynomial 
extrapolator 

XM(n)  is  the  current  model  state  vector  such  as 
XM(n)  =  F.XM(n-l)-t-0.u(n-l) 
kj  off-line  constants  given  by  the  CAD  tool 

T 

Vjj  off-line  vector  given  by  the  CAD  tool 

The  figure  U  shows  P.F  C.  law  in  plemented  in  the  on-board 
system  real  time  computer  Results  are  shown  in  the  next 
section. 

In  appendix  B  is  shown  the  listing  generated  by  the  CAD 
tool. 


4.  CCWCLUSICW 

In  this  paper,  it  has  been  discussed  of  a  new  guidance  and 
control  technique  s  Predictive  Functional  Control.  It  was 
shown  that  this  technique  is  fiilly  compatible  with  CAD 
integrated  design  and  allows  rapid  control  laws  prototyping. 
Two  applications  were  present^.  Obtained  results  are  quite 
significant.  For  the  missile  guidance  law,  the  miss  distance 
was  reduced  of  30  to  60  %.  For  the  turret  control,  it  was 
shown  that  good  pe'  rrmance  and  robustness  could  be 
obtained  under  wide  operating  conditions.  Compared  to  the 
previous  SBC  Control  law,  the  robustness  and  the  closed 
loop  dynamic  have  been  increased  by  SO  %  and  20  % 
respectively. 
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FIGURE  13  :  P.P.C.  law 


3.2.3.  RESULTS 

The  obtained  results  for  a  trackmg  sequence  are  presented 
here.  The  figure  14  shows  a  step  response  of  the  ninet  and  a 
non  moving  target  tracking.  The  tracking  error  remains  in 
the  specified  values.  Tlie  rallying  time  (without  overshoot) 
IS  very  good. 

The  figure  15  shows  the  tracking  of  a  rectilinear  uniform 
flight  al  a  constant  altitude.  Here,  the  target  is  more 
evolutive,  but  the  tracking  error  always  remains  in 
accepiable  values. 


TCNf$/« 
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APPENDIX  A 

A.I.  ON-UNECX)NTROLCX»BVrATKW 


n« 

e(n+i)  =  e(n)  +  5^ej(n).ij 

j=l 


O^i^h 


(A.5) 


The  line*!  model  of  the  proce*s,  in  stage  space  fotm.  is 
introduced  in  the  control  elements : 


e(n)  being  the  difference  at  instant  n.  The  procedwe  of 
predicting  this  difference  with  n*  2  1,  i.e.  by  considering 
6(n-H)  rt  e(n),  is  called  self-compensation. 

The  control  is  calculated  by  minimization  of  the 
criterion : 

"h  .2 

D(n)  =  51  {  yp("+*'j)  •  yrln+hj)  j  (A.6) 

j>=l 

Jhj)j=j,nh  *’*‘"8  coincidence  points  with  hnj,  *  h. 
The  number  of  coincidence  points  must  be  at  lewt  equal 
to  the  number  of  base  fimetions. 


HGURE16 
with  the  notations  : 
p  f  process 

C  :•  setpoint 

u  ;  control  variable 

M  model 

y  :  output 

The  reference  trajectory  yR  on  the  prediction  horizon  of 
length  h  is  *  first  order  trajectory  defined  by : 

c(n+t)-yr(n+t)»a'{c(n)-yp(n))  OSiSh  (A.l) 
with  OSoSi 

The  future  setpoint  (known  or  extrapolated)  is  expressed 
in  a  polynomial  form  ;■ 

ric 

c(n+i)  =  51«j(")‘^ 

j=0 

The  future  control  sequence  it  structured  as  a  linear 
combination  of  bate  functions  : 

nb 

u(n+i)=  51>‘k(n)'‘bk(>) 

k=l 


At  each  instant,  the  control  calculation  it  thus  reduced  to 
the  determination  of  the  coefficients  [  Pkl")}  k=l.nb‘ 

The  predicted  process  output  is  given  by  : 


The  PFC  algorithm  yields,  for  the  first  value  of  the  future 
control  sequence  which  is  the  value  to  be  applied  at 
instant  n,  the  following  linear  control  expression  ! 


u(n)  =  ko.{co(n)  -  yp(n))  + 
max(nc.ne) 

5^  kj.{  Cj(n)  -  ej(n))  +sT.Xm 
j»l 

Where  the  coefficients  ko.  kj  and  y.  ate  calculated  off¬ 
line  X_  denotina  the  model  state  vector. 


A.2.  EXTENSIONSTOTHEBASICALGORTTHM 

Constraint*  on  u,  <i  and  0  can  be  dealt  with  by  applying  a 
particular  suategy  without  modifying  the  linear  conuol 
expression.  In  this  strategy,  the  part  of  the  future  model 
output  ymltt+t)  depending  on  the  past  it  calculated  by 
using  the  applied  (i.e.  constrained)  control  values. 


Modification  of  the  criterion  (A.6)  by  adding  a  quadratic 
lerm  in  u  or  iu  variations  can  be  used  for  control  energy 
reduction  and  smoother  control.  The  modified  criterion  it 
of  the  form  :• 

D(n)=5)  {  yp(n+>'j)  •  yt(n+hj))^  +  ^{  aM")}  (A.8) 

J=> 


This  yields  to  the  linear  control  expression  : 

u(n)  =  ko.{co(n)  -  yp(n)}  + 
max(nc.nc) 

5)kj.{cj(n)-ej(n)}-^ 

j=* 

vTXm +  ?•«("•') 

where  Iq).  kj's,  y  and  P  are  calculated  off-line. 


yp(n+i)  =  ym("+')  +  *("+0  0  S  i  i  h  (A.4) 

e(n+i)  denoting  the  predicted  difference  between  the 
process  and  model  outputs,  obtained  through 
observations  on  a  past  horizon,  by  a  polynomial 
extriqiolation 


Feedforward  compensation  of  a  measured  perturbation  6 
is  achieved  by  including  a  prediction  of  this  perturbation 
in  the  process  output  prediction  t  in  this  case,  PFC  works 
with  an  additional  model  Mg  conesponding  to  the  d  — > 
yp  transfer  as  shown  in  the  figure  below  :■ 


HGUREl? 


There  alto,  a  linear  regulator  it  obtained,  its  expression 
is  given  by : 

u(n)  -  ko.{eo(n)  -  yp(n))  + 
max(nc,ne) 

S  kj.  ( cj(n)  ■  ej(n)}  - 

"8  ^ 

*'8j-8j(n)  +  (A.10) 

j=0 


APPENDIX  B 


Example  of  CAD  tool  outputs  for  bearing  axis. 
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***************************** 
PARAMETRES  DE  LA  SIMULATION  : 

»******•***********••**«*«•«* 


periode  de  simulation  -  0.20000E-01  sec. 

PROCESS  ; 


retard  ■■  0.00000  secondes 
FONCTION  DE  TRANSFERT  CONTINUE  : 
numerateur  «  1.0000  *  p**  o 

denominateur  «  0.00000  *  p»*  0 

+  1.0000  *  p**  1 

+  0,30000E-01  *  p**  2 


PERTURBATION  D'ETAT  : 


perturbation  en  entree  -  0.00000  ♦  0.00000  *  t 

bruit  sur  sortie  :  ecart-type  -  0.00000  f.coupure  -  0.00000 

CONTRAINTES  : 


commando  max. 
oommande  min. 
gradient  max. 


1.5000 

-1.5000 

1.6000 


CONSIGNE  : 


conalgno  Ineonnue  generee  aoua  la  forme  : 

oonalgne  -  1.5700  +  0.00000  .t  ♦  0.00000  •c2  ♦  0.00000 

PARAMETRES  DE  LA  COMMANDS  : 


•t3 


perlode  de  oommande  -  0.20000E-01  sec. 
MODELE  : 


retard  *  0.00000  secondes 
FONCTION  DE  TRANSFERT  CONTINUE  : 
numerateur  -  1.0000  *  p‘«  0 

denominateur  >•  0.00000  *  p»*  0 

t  1.0000  *  p«*  1 

+  0.30000E-01  *  p«*  2 

MODELE  DISCRETISE  a  :  0.20000E-01  s 
matrice  d' evolution  F  : 

1.00000  0.145975E-01 

0.000000  0.513417 

matrice  de  commande  G  : 

0.540251E-02 

0.4865S3 

matrice  d' observation  C  : 


I8<-15 


1.00000  0,000000 

BASE  ,  REF.  ,  COINCIDENCE  : 


nombre  de  fonctlons  de  base  •  2 
echelon 
Tcmpe 

traj.de  ref.  du  ler  ordre  :  tpa  rep  »  0.10000  see, 

nbre  de  pts  de  coincidence  ••  2  :  0.40000E-01  0.80000£>0l 

EXTRAPOLATEUR  DE  CONSIGNE  ; 


degre  de  I'extrapolateur  de  consigne  •  2 

nombre  de  consignes  passees  utilisees  *  S 

AUTO-COMPENSATEUR  : 


degre  du  polynome  extrapolateor  de  d.o.m.  -  1 
nombre  de  d.o.m.  passees  considerees  *10 
tps  rep  filtre  de  d.o.m.  •  0.50000  sec. 

EQUATIONS  DU  REGULATEUR  : 


u(n)  -  kO  (  c0(n)  -  sp(n)  ) 

+  kl  (  ol(n)  -  dl(n)  1  <•  k2  (  o2(n)  -  d2(n)  )  +  k3  t  c3(n)  -  d3(n)  ) 
+  vx.xm(n) 


kO  ■  47.1561  kl  -  124.841  k2  -  191.746 

vx  •  0.000000  -1.49681 


k3  -  0.000000 


EXTRAPOUTEUR  DE  CONSIGNE  : 


cm  •  moyenn.  de.  c{d-i)  pour  1*0,  ...,  horizon  de  consigne.  passees 

01 (nl  -  somme  sur  1  de  (  yc(l,l)  (  c(n-l)  -  cm  )  | 

e2(n)  "  somme  sur  1  de  (  yc(l,2)  (  c{n-l)  -  cm  )  ) 

e3(n)  -  somme  sur  1  de  (  yo(i,3)  (  o(n-l)  -  cm  )  ) 

c0(n)  -  cm  -  me(l)  cl  (n)  -  me(2)  c2(n)  -  me(3)  c3(n) 


me 

-2.5000 

9.1667 

O.OQOOO 

yc( 

0, 

)> 

0.58929 

0.8928eE-01 

o.oooco 

yc( 

1, 

)- 

-0.35715E-02 

-0.17857E-01 

0.00000 

yc( 

2, 

)- 

-0.32857 

-0.71429E-01 

0.00000 

yo( 

3, 

)- 

-0.38571 

-0.71429E-01 

0.00000 

yo( 

4, 

)- 

-0.17500 

-0.n857E-01 

0.00000 

yc( 

5, 

0.30357 

0.89286E-01 

0.00000 

EXTRAPOIATEUR  DE  D.O.M.  : 


dm  -  moyenne  des  doraf(n-l)  pout  1-0 . horizon  de  dom  passees 

dl(n)  -  somme  sur  1  de  [  yd(l,l)  (  doraf(n-l)  -  dm  )  ) 

<i2(n)  -  somme  sur  1  de  (  yd(l,2)  (  domf(n-i)  -  dm  )  ] 

d3(n)  -  somme  sur  i  de  (  yd(i,3)  (  domf(n-i)  -  dm  )  ) 

yd(  0,.)*  0.45455E-01  0.00000  0.00000 

y<i(  1,.)"  0.36364E-01  0.00000  0.00000 

yd(  2,.)*  0.27273E-01  0.00000  0.00000 


!g-16 


ycl( 

3, 

.)-  0.18182E-01 

0.00000 

0.00000 

yd( 

4, 

.}=  0.90909E-02 

0.00000 

0.00000 

yd( 

5, 

.)=  0.00000 

0.00000 

0.00000 

yd( 

6, 

.)-  -0.90909E-02 

0.00000 

0.00000 

yd( 

7, 

.)-  -0.18182E-01 

0.00000 

0.00000 

yd( 

8, 

.)=  -0.27273E-01 

0.00000 

0.00000 

yd( 

9, 

.)=  -0.36364E-01 

0.00000 

0.00000 

yd(l0. 

-0.454S5E-01 

0.00000 

0.00000 
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ANALYST  WORKBENCH 

Thomas  F.  Reese,  Frank  Aimogida 
Naval  Weapons  Center 
China  Lake.  CA  93555-6001,  USA 


SUMMARY 

The  Analyst  Workbench  was  developed  at  the  Naval 
Weapons  Center  to  provide  analysts  with  the  ability 
to  interactively  visualize  flight-test  and  simulation 
results  in  the  study  of  missile  performance  and 
effectiveness.  This  technology  integrates  tools  and 
utilities  into  one  software  package  that  not  only 
assists  analysts  in  gathering  data,  but  that  provides 
the  means  to  analyze  and  assimilate  the  data. 
Visualization  technologies-such  as  the  Analyst 
Workbench'-enhance  communication  between 
computer  and  analyst,  analyst  and  analyst,  and  analyst 
and  management.  Current  methods  are  an  inefficient 
use  of  analysts'  time  and  talents.  The  Analyst 
Workbench  helps  eliminate  the  large  portion  of  time 
analysts  now  spend  just  searching  for  the  data  so  this 
valuable  time  may  be  spent  analyzing  these  data 
instead.  Using  these  technologies  to  increase 
personnel  productivity  and  organization 
communications  will  ensure  the  reliability  and 
efi'eciiveness  of  current  and  future  guidance  and 
control  systems  throughout  the  North  Atlantic  Treaty 
Organization  (NATO). 

INTRODUCTION 

Analysts  involved  in  the  study  of  missile  performance 
and  effectiveness  require  telemetry  data  and 
simulations  to  conduct  significant  analyses.  As  a 
result,  these  analysts  arc  inundated  with  the  data 
generated.  Using  an  exclusively  numerical  format, 
the  analysts  cannot  effectively  intciprct  these  valuable 
data. 

Analysts  need  an  alternative  to  numbers.  They  need 
the  ability  to  visualize  these  data  and  the  tools  to 
answer  key  questions,  such  as 

Did  the  subsystems  function  satisfactorily? 

Did  the  subsystems  function  at  the  proper  time? 

Did  any  evidence  of  unexpected  or  marginal 

subsystem  performance  exist? 

The  Analyst  Workbench,  developed  at  the  Naval 
Weapons  Center,  provides  analysts  with  the  ability  to 


interactively  visualize  flight-test  and  simulation 
results.  The  Analyst  Workbench  supplies  the  tools 
needed  to  answer  the  key  questions  listed  above. 
These  abilities  are  imperative  to  ascertain  the 
integrity  of  the  analyses,  to  provide  insights  into 
subsystem  performance,  and  to  share  those  insights 
with  others. 

BACKGROUND 

Missile  system  analysis  has  been  conducted 
traditionally  by  means  of  strip  charts  and  computer 
printouts.  Analysts  manually  evaluate  the  strip 
charts  for  anomalies  for  each  data  parameter  on  the 
checklist  and  write  the  results  on  a  chart  for  daia-entry 
personnel  to  place  into  the  database.  After 
completing  the  evaluation  procedure  for  each  item  on 
the  checklist,  the  analyst  conducts  a  statistical 
analysis  to  detect  trends  within  these  daui.  After  all 
the  analyses  are  complete,  a  report  is  generated  and 
delivered  to  the  appropriate  program  office. 

Current  methods  arc  an  inefficient  use  of  the  analyst’s 
time  and  talents.  The  strip  charts  and  data  tapes  arc 
never  easily  accessible.  The  analyst  spends  a  large 
portion  of  time  just  searching  for  the  data  rather  than 
interpreting  them.  The  Analyst  Workbench  provides 
the  tools  required  to  integrate  and  make  the  data 
accessible  so  the  analyst  can  conduct  a  complete  and 
full  analysis  within  a  reasonable  time. 

The  interactivity  of  the  Analyst  Workbench  provides 
a  natural  means  for  an  analyst  to  communicate  with 
data  by  manipulating  their  visual  representation. 
This  method  enables  the  analyst  to  control  the 
analysis  and  find  anomalies.  Simply,  the  Analyst 
Workbench  increases  the  analyst's  productivity. 

OVERVIEW 

The  Analyst  Workbench  is  a  scries  of  interactive 
utiliues  integrated  to  form  a  software  package.  The 
software  components  communicate  through  shared 
memory  and  data  files.  Fig.  1  shows  the  software 
components  and  their  siage  of  development. 
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Fig.  1.  Analyst  Workbench  Software  Components  and  Percent  Completed. 
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DATA  EXTRACTION  AND 
REDUCTION  UTILITIES 

Before  any  analyses  can  be  conducted,  the  analyst 
needs  to  acquire  telemetry  data.  Flight-test  telemetry 
data  arc  normally  stored  on  magnetic  tape  by  test- 
range  personnel.  The  data  tapes  are  then  transferred  to 
the  analyst  for  analyses.  The  data  extraction  and 
reduction  utiiities  select  individual  telemetry  channels 
from  data  tapes  and  install  them  into  the  database. 
For  some  flight  tests,  the  amount  of  data  can  reach  up 
into  the  gigabytes.  Dealing  with  this  "big  data”  by 
conventional  means  requires  laborious  tape  transfers 


and  time-emsuming  storage-management  techniques. 
Currently,  we  only  have  hmd  disk  drives  available  for 
data  storage.  Future  plans  involve  transferring  the 
data  to  a  combination,  erasable  optical,  and  worm 
(write  once,  read  many)  optical  disk.  This  storage 
strategy  will  provide  for  on-line  access  of  telemeuy 
and  simulation  data  for  the  analyst. 

The  data-extraction  utilities  are  menu  driven  and 
usually  must  be  customized  for  each  type  of  telemetry 
data  set  (Fig.  2).  Once  a  format  is  determined,  a 
computer  scientist  can  write  a  routine  to  extract  the 
data  and  add  them  to  the  utility. 
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Unload  tape 

Histoaram 

Make  flloht  path 

Automatic 
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Unload  channel 

Print  plot 

Exit 

Exit 

Exit 

Fig.  2.  Data  Extraction  and  Reduction. 


Currently,  the  reduction  utility  provides  various  toots 
to  reduce  the  amount  of  data  stored.  First,  the  utility 
evaluates  each  telemeuy  channel's  update  frequency 
and  places  the  beginning  time  and  update  frequency  in 
the  header  of  the  file.  This  procedure  eliminates  the 
need  to  store  the  time  for  each  time  step. 

Second,  the  reduction  utility  eliminates  data 
duplication.  The  utility  determines  if  the  telemetry 
value  is  equal  to  the  previous  value,  and  if  so,  does 
not  store  these  daui  on  disk.  When  the  data  value 
does  change,  the  time  and  value  are  stored  in  the 
database.  This  simple  process  can  reduce  a  file  size 
significantly. 

Several  data-smoothing  algorithms  were  considered; 
however,  in  some  cases  the  algorithms  eliminated  key 
data  elements  required  for  analyses.  The.se  algorithms 
are  still  implemented,  but  very  rarely  are  they  used. 
Analysts  can  usually  tell  noise  from  real  data. 


DATABASE  UTILITIES 

The  database  utilities  provide  a  series  of  interactive 
information  storage  and  retrieval  routines  that  enable 
the  analyst  to  query  the  database  for  a  group  of 
channels,  an  individual  channel,  documenuiticn,  and 
overall  data  trends. 

Currently,  the  database  consists  of  FLTNO, 
GUIDANCE,  and  VEHICLE  parameters.  Each  of 
these  icons  is  shown  in  (Fig.  3). 

When  the  analyst  needs  data  from  a  particular  flight 
test,  the  mouse  is  positioned  above  the  FLTNO  icon 
and  the  left  mouse  is  pressed  (Fig.  4).  At  this  point, 
the  utility  searches  the  database  for  available  flight- 
test  data  sets.  The  analyst  then  reviews  the  list  and 
selects  the  appropriate  data  set.  This  process  sets  the 
"current  path"  in  the  database  and  all  data  are  retrieved 
from  this  path.  To  alter  the  path,  the  analyst  can 
reselect  the  FLTNO  icon  and  repeat  the  orocess. 


Fig.  4.  User  Selects  FLTNO  Icon, 


it?**? 
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Once  the  current  path  is  set,  the  analyst  can  select  the 
GUIDANCE  or  VEfflCLE  icons.  The  GUIDANCE 
icon  accesses  the  telemetry  data  related  to  the  guidance 
systems,  and  the  VEHICLE  icon  accesses  the 
telemetry  data  associated  with  the  propulsion, 
mechanic,  electrical,  pneumatics,  fuel,  and  ordnance 
subsystems.  Additional  icons  can  be  added  to  suit  the 
analyst.  Once  selected,  the  utility  searches  the 
database  for  available  groups  of  telemetry  data  and 
provides  a  popup  menu  of  the  groups.  The  analyst 
can  move  the  mouse  over  the  selected  group,  toll  over 
the  menu  to  get  an  additional  menu  of  the  telemetry 
channels  in  that  group  (Fig.  5).  The  analyst  may 
now  select  a  telemetry  channel  that  assigns  that 
channel  to  the  "current  flic."  The  current  file  is  used 
by  many  of  the  routines  described  in  this  paper. 

Each  of  the  telemetry  channels  has  an  associated 
documentation  file.  This  file  is  a  text  Hie  that 
discusses  the  particulars  of  each  channel.  The  analyst 
may  access  these  flies  by  selecting  a  channel  by  ^e 
previous  method,  then  selecting  the  TOOLS  icon,  and 
making  a  select  ion  from  the  documentation  menu. 
The  documentation  utility  then  searches  for 
information  on  the  current  file  and  opens  a  window 
that  displays  it  to  the  user  (Fig.  6). 

Stored  in  a  separate  part  of  the  database  are  the  data 
trends  for  each  of  the  analysis  criteria,  such  as  "fuel 
bum  rate."  To  review  the  data  trends,  the  analyst 
selects  the  TOOLS  icon  and  then  selects  TREND 
ANALYSIS  from  the  menu.  The  utility  then 
searches  the  database  for  a  list  of  available  trend 
studies  and  presents  them  to  the  analyst.  At  this 
point,  the  analyst  selects  a  data-trend  study  and  a 
window  is  opened  showing  a  plot  of  the  current  trend 
and  the  equation  used  to  calculate  this  value.  In 
addition,  the  analyst  is  provided  with  an  additional 
menu  to  add,  delete,  or  modify  the  data  in  the 
database. 

To  conduct  a  complete  analyses,  aii  analyst  needs 
statistical  tools  to  evaluate  telemetiy  data.  Currently, 
the  statistical  tools  available,  although  rather  limited, 
uo  provide  the  basic  statistical  utilities  like  mean, 
variance,  and  standard  deviation. 

A  tool  is  currently  under  development  to  enable  the 
analyst  to  rapidly  customize  his  or  her  own  statistical 
routines  and  add  them  to  a  popup  menu  (Fig.  7). 

The  aforementioned  utilities  and  tools  provide  the 
analyst  with  access  to  all  the  telemetry  data  to 
evaluate  flight-test  and  simulation  results.  However, 
analysts  need  to  see  the  data  to  conduct  their  analyses. 

PLOT  AND  TIME  UTILITIES 

Analysts  like  to  use  strip  charts  and  numbers. 
However,  spreading  a  strip  chart  over  a  conference 


table  is  not  the  most  efficient  means  of  evaluating  the 
data.  The  plot  and  time  utilities  of  the  Analyst 
Workbench  provide  an  electronic  strip  chart  of 
telemetry  channels  and  a  digital  readout  of  the 
numbers. 

The  electronic  strip  chart  depicted  in  Fig.  8  is  used  to 
display  a  time  segment  of  four  selected  telemetry 
channels.  Using  the  video  tape  recorder  (VTR) 
controls,  the  analyst  can  move  time  by  pressing 
REWIND,  FFWD,  STEP->,  <-STEP,  PAUSE,  or 
PLAY.  This  time  is  stored  in  shared  memory  for 
other  processes  within  the  Analyst  Workbench  to 
access. 

The  numerical  readouts  shown  in  the  upper  left  comer 
(Fig.  8)  display  the  telemetry  channels'  numeric 
values  in  the  center  of  the  electronic  strip  chart.  The 
analyst  may  position  the  mouse  over  a  readout  until  a 
readout  lights  up  and  enables  the  sliding  scale  for  that 
particular  telemetry  channel.  Once  a  sliding  scale  has 
been  enabled,  a  r<^  light  on  the  lower  border  of  the 
readout  is  turned  on  and  the  scale  associated  with  that 
telemetry  channel  tracks  along  the  mouses  horizontal 
position  on  the  screen.  Attached  to  the  left  and  right 
sides  of  the  scale’s  vertical  line  are  rectangles 
containing  the  time  and  value  of  the  telemetry 
channel.  The  analyst  may  move  the  rectangles  by 
pressing  the  left  mouse  button  and  moving  the  mouse 
vertically.  To  disable  the  sliding  scale,  the  analyst 
presses  the  middle  mouse  button. 

The  labels  on  the  left  side  of  the  utility  display  the 
telemetry  channels  assigned  to  each  data  trace.  The 
analyst  may  turn  a  trace  on  or  off  by  centering  the 
mouse  over  the  rectangle  until  the  rectangle  lights  up 
and  by  then  pressing  the  middle  mouse  button.  To 
display  a  different  telemetry  channel,  the  analyst 
retrieves  a  current  file  from  tlie  database,  as  mentioned 
previously,  and  positions  the  mouse  over  the  desired 
trace  recumgle  until  that  rectangle  is  lighted,  then 
presses  the  left  mouse  button.  At  this  point  the 
software  removes  the  existing  traces  data,  notifies  the 
analyst  of  the  file  being  loaded,  and  then  loads  the 
new  telemetry  channels  file  into  memory  (Fig.  9). 

The  beginning,  ending,  and  current  time  digital 
readouts  depicted  in  Fig.  9  enable  the  analyst  to 
manually  alter  the  time  to  rapidly  increase,  decrease 
the  time  scale,  or  move  current  time  to  a  particular 
telemetry  segment  The  ">"  arid  "<"  icons  are  used  to 
move  the  beginning  and  ending  times  incrementally. 
The  analyst  positions  the  mouse  over  the  icon  until 
that  icon  lights,  then  presses  the  right  mouse  button. 
The  longer  the  mouse  button  is  pressed,  the  faster  the 
time  scale  changes. 
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Fig.5.  Guidance  Database  Menu. 


Fig.  6.  Documentation  on  Telemetry  Data. 
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Fig.  7.  Statistical  Utilities. 
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Fig.  8.  Electronic  Strip  Chart. 
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Fig.  9,  Loading  a  New  Telemetry  Channel. 


The  vertical  scales  for  each  telemetry  channel  can  be 
modified  individually.  The  UP  and  DOWN  icons 
shown  in  Fig.  9  are  used  to  increase  or  decrease  the 
scales  shown  on  the  display.  The  scales  that  are 
turned  off  arc  not  modified.  Again,  the  longer  the 
mouse  is  pressed,  the  faster  the  scale  changes. 

The  versatility  of  the  plot  and  time  utilities  provide 
many  of  the  visualization  tools  necessary  to  analyze 
telemetry  channels.  The  analyst  can  rapidly  access, 
display,  and  manipulate  the  data  used  for  analysis. 
The  plot  and  time  tool  will  not  eliminate  the  need  for 
strip  charts.  Therefore,  plans  are  underway  to 
implement  an  interface  to  a  strip-chart  recorder. 
However,  this  utility  does  satisfy  most  of  the  strip- 
chart  needs  of  the  analyst. 

OUT-THE-WINDOW  TOOL 

The  out-the-window  tool  provides  a  visual 
representation  of  the  missile  flight  parameters,  seeker 
characteristics,  and  physical  test  environment. 
Fig.  10. 


The  U.S.  Defense  Mapping  Agenda  (DMA)  provides 
digital  terrain  elevation  data  (DTED)  and  digital 
feature  analysis  data  (DFAD)  to  U.S.  Government 
Agencies.  This  product  is  widely  used  throughout  the 
analysis  community. 

The  DTED  data  are  composed  of  a  matrix  of  elevation 
data  within  a  1-degrce  latitude  by  a  1-degrcc  longitude 
quadrangle.  The  d'stance  between  cell  elements  is 
approximately  100  meters.  Many  attempts  at 
generating  a  realistic  out-the-window  view  for  flight 
simulation  have  been  stopped  as  a  result  of  the  large 
amount  of  data.  The  Analyst  Workbench  does  not 
attempt  to  generate  a  realistic  out-the-window  view. 
The  out-the-window  utility  does  a  simple 
representation  of  the  terrain  and  target.  The  out-the- 
window  scene  is  a  modified  product  produced  at  the 
Naval  Postgraduate  School,  Monterey,  Calif. 
(Reference  1). 


Fig.  10.  Out-thc-Window  View. 


The  Naval  Weapons  Center  needed  to  modify  this 
software  to  fit  the  needs  of  the  Analyst  Workbench. 
First,  the  software  needed  to  be  driven  by  an  autopilot 
file  and  time  from  shared  memory.  An  autopilot  file 
for  each  flight  test  is  created  from  the  telemetry  and 
tracking  data.  The  autopilot  file  is  read  in  and  creates 
a  linked  list  of  time,  x,  y,  z,  heading,  climb,  roll,  and 
velocity  in  internal  random-access  memory  (RAM). 
Second,  the  Heads-Up  display  needs  to  be  modified  fw 
each  missile  type  analyzed.  This  modification 
includes  seeker  slate  variables  and  seeker  field  of 
view.  Third,  the  targets  and  environment  need  to  be 
displayed  as  icons  on  the  terrain. 

As  the  time  is  modified  by  the  VTR  controls,  the 
out-ihc-window  utility  alters  the  perspective  of  the 
missile  and  updates  the  Heads-Up  display.  This 
procedure  provides  the  analyst  with  visual  cues  of 
anomalies  within  the  test.  Using  the  visual 
representation  of  the  missde-body  angles,  seeker  field 
of  view,  and  seeker  state  variables,  the  analyst  can 
understand  and  communicate  better  the  complex 
relationships  between  the  target,  environment,  and  the 
missile. 

When  computer  graphics,  processor,  and  me.'nory 
speeds  iiKrease,  a  more  realistic  out-the-window  view 
will  be  considered,  but  now  the  Naval  Postgraduate 
School's  software  works  fine. 


PLAN  VIEW  UTILITY 

The  plan  view  utility  provides  a  three-dimensional 
perspective  of  the  missile  flight  on  the  test  rang* 
An  icon  of  the  test  vehicle  depicts  the  location, 
altitude,  and  seeker  field-of-view.  Icons  of  the  targets 
and  key  features  are  also  displayed  (Fig.  1 1). 

Using  this  utility,  the  analyst  can  see  a  perspective 
view  of  the  missile,  seeker  range,  and  field  of  view. 
A  popup  menu  is  provided,  which  enables  the  analyst 
to  zoom  and  pan  into  the  test  area.  These  features 
provide  the  analyst  with  a  better  understanding  of  the 
seeker  interactions  with  the  target,  such  as  several 
RF-emitter  sources. 

DATA  VIEW  UTILITY 

The  data  view  utility  provides  an  interactive  set  of 
utilities  that  enables  the  analyst  to  tie  bar  charts, 
digital  readouts,  dials,  and  hismgrams  to  an  individual 
or  group  of  telemetry  channels.  If  a  data  paameter 
exceeds  the  maximum  or  minimum  threshold  entered 
by  tlie  analyst,  the  analyst  is  alerted. 
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Fig.  11.  Plan 


When  the  analyst  selects  the  data  view  tool  from  the 
TOOLS  icon,  a  window  is  opened  that  displays  icons 
for  each  graph  type  (Fig.  12).  The  analyst  may  then 
selects  a  tclemctiy  channel  from  the  current  file  and 
assigns  it  to  a  particular  graph.  After  the  selection  is 
complete,  the  tool  prompts  the  analyst  to  enter  the 
minimum  and  maximum  values  that  are  allowed. 
Then  the  analyst  may  place  the  graph  in  the  desired 
spot  in  the  window  by  ntoving  the  mouse  to  the 
lower  left-hand  comer  and  pressing  the  right  mouse 
button.  At  this  point,  the  data  file  is  read  into  a 
linked  list  in  internal  memory,  and  the  display  is 
initialized  to  the  time  in  shared  memory. 

As  time  progresses,  the  data  view  tool  accesses  the 
lime  and  displays  the  telemetry  value  at  that  time.  If 
the  value  exceeds  the  minimum  and  maximum  value 
input  by  the  analyst  the  tool  alerts  the  analyst,  with  a 
flashing  red  light  and/or  a  bell  sound  from  the 
keyboard. 

AUTOMATIC  REPORT  WRITER 

The  automatic  report  writer  (Fig.  13)  is  a 
documentation  package  customized  for  an  individual 
missile  program  office.  An  analyst  interactively 
accesses  standardized  forms  that  guide  the  analysis  and 
fulfill  the  laborious  documentation  requirements  of 


View  Display. 


the  analyst.  After  completing  the  analyses,  the 
analyst  saves  the  completed  forms  in  the  database 
with  the  data,  keeping  them  together  for  future 
reference. 

LIVE  VIDEO  UTILITY 

The  live  video  utility  provides  the  ability  to  display 
live  video  in  a  window  on  the  Workbench  (Fig.  14), 
The  VTR-type  controls  in  the  plot  and  time  tools 
advance  u.v  tape  to  synchronize  the  video  with  the 
data.  This  utility  enables  the  analyst  to  see  and  hear 
the  live  flight  test  and  help  identify  criucal  data 
segments  within  the  test. 

WARHEAD  UTILITIES 

The  warhead  utilities  provide  the  ability  to  study  the 
characteristics  of  warhead/target  interactions.  The 
utilities  require  input  of  the  missile-trajectory  data 
just  before  impact,  the  target  name,  weapon  fuze 
type,  and  warhead  type.  The  utilities  then  smooth  the 
data  into  a  flight  path.  Then  the  utility  recreates  th'* 
missile  endgame  with  the  weapon/target  fuze 
interaction.  The  utility  displays  of  the  warhead- 
detonation  pattern  on  the  target  and  calculation  of  the 
probability  of  kill  for  the  endgame  geometry  and 
variations. 
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Fig.  12.  Daia  View  Graphs. 


FUZE  SPACE  UTILITIES 

The  fuze  space  utilities  provide  the  ability  to  study 
the  general  characteristics  of  various  fuzeAvarhead 
interactions  with  a  target.  These  utilities  were 
develop^  both  to  understand  the  interactions  and  to 
assist  with  fuze  optimization  studies,  The  utilities 
display  the  fuze  point,  color  coded  for  probability  of 
Kill,  for  a  set  of  parallel  trajectories  around  a  target. 
Multiple  sets  of  data  can  be  overlayed,  or  plots  of 
probability-of-kill-versus-miss-distance  or  circular 
error  probable  (CEP)  can  be  displayed. 
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Many  papers  have  already  been  written  about  the  general 
purpose  programming  language  Ada.  The  authors  of  these 
papers  often  draw  a  number  of  contradictory  conclusions  such 
as  "users  running  Ada  keep  complaining  about  Ada«  but  none 
of  them  would  drop  Ada  for  another  language"  or  "Ada  isn't 
perfect,  but  it*8  the  best  existing  language",  or  "such  a 
language  could  never  be  used  for  embedded  applications  with 
stringent  real-time  constraints". 

In  this  paper  we  do  not  claim  to  draw  any  iinal  conclusion 
regarding  Ada  -  it  would  be  too  presumptuous  on  our  part  to  do 
so  in  a  domain  under  full  expansion  -  but  we  do  propose  some 
important  reflections  regarding  design  methods,  real  time 
aspects,  and  tools  needed,  considering  our  experience  with 
combat  aircraft  embedded  software. 

CHARACTERISTICS  OF  AN  EMBEDDED 
SOFTWARE 


Real  Time.  Regponge  Time.  Memory  and  Throughput 
Constraints 


Because  of  the  nature  of  the  tasks  that  it  has  to  perform, 
mission  computer  soRware  is  subjected  to  such  constraints  that 
the  choice  of  the  programming  language  is  of  utmost 
importance. 


Real  Time  constraints  impose,  first,  a  real-time  architecture 
capable  of  handling  periodic  as  well  as  random  events  and 
assure  a  consistency  in  the  processed  data  set.  The  choice  of 
what  will  be  called  later  on  the  real-time  monitor  is  vital  to 
meet  these  requirements. 


Response  time  requirements  also  are  fundamental.  Indeed, 
mission  computer  software  controls  and  manages  the 
information  made  available  to  the  pilot.  To  do  ao,  it  must  assure 
that  the  response  time  between  a  pilot  action,  for  example,  and 
Its  acknowledgment  on  the  rlght-aide  multifunction  display 
takes  less  than  X  ms. 


Prior  to  detailing  our  roflectluns  in  subsequent  chapters,  it  is 
paramount  to  know  the  characteristics  of  the  projects  on  which 
our  experience  is  baaed.  In  fact,  the  characteristics  of  a 
compiler,  a  configuration  manager,  or  an  embedded  software 
are  very  different. 

There  are  two  mam  types  of  characteristics  :• 

•  Those  ofthesoltwaro  Itself. 

•  Those  of  the  software  development  procei,s 

Characteristics  of  the  software 

Quality  factors 

The  primary  quality  factors  in  the  development  of  combat 
aircraft  embedded  snitware  are  (if  only  three  are  Ui  be 
retained) : 

•  Robustness :  in  fact,  mission  computer  tasks  have  become 
more  and  more  complex  and  even  critical  regarding  pilot 
safety  lin  the  terrain-following  and  guidance  phases,  for 
example).  Thus,  the  software  must  be  protected  against  its 
own  defects  or  an  unforeseen  behavior  of  i(s  environment. 


Memory  and  throughput  constraints  will  be  discussed  below 
when  the  efficiency  quality  factor  i, detailed. 


Considering  the  more  than  20  year  life  cycle  of  a  combat 
aircraft  and  the  improvements  made  in  the  n  mpuler 
throughput  field,  a  new  quality  factor  has  ar.ierged,  and  it  will 
have  to  be  added  to  the  previoua  ones ;  poriabiiity.  This  ii 
particularly  true  for  RAFALE  tinea  the  initial  opera tiona  were 
carried  out  on  a  68D20.baaed  PMP  compuur  ayatam,  which  will 
be  replaced  by  a  SPARC-based  CMPcompuler  ayatam.  Thus, 
tha  naceaaity  is  apparent  regarding  the  choice  of  language  we 
will  have  to  make  to  assure  portability.  Ada  was  choten  over  C 
because  of  its  higher-level  concepte  confirmed  after  a  aeries  of 
tests. 

Characteristics  of  the  software  development 
process 

Software  development  process  requirements,  although  they  are 
not  significant  m  the  choice  of  language,  ace  signincant  in  the 
choice  of  software  development  resources  associated  with  this 
language. 


e  Maintainability  and  adaptability :  an  embedded  software 
evolves  throughout  the  life  cycle  ufun  aircraft,  that  is, 
over  roughly  20  years  (for  example,  an  average  of  five 
modifications  per  working  day  during  the  first  eight  years 
of  the  development  process  of  the  MIRAGE  2000  export 
was  experienced  I.  The  software's  structure  as  well  as  the 
associated  documentation  are  essential  elements  for  the 
acceptance  of  such  facUirs. 

a  Giriciency :  in  spite  of  the  tremendous  nnpruvenient  in 
technologies  the  last  few  years,  it  is  a  must  that  the 
memory  occupation  and  computer  throughput  required  by 
the  software  be  controlled  and  managed. 


Initial  Development  Time 


The  development  of  software  for  combat  aircraft  embedded 
computers  is  characteriied  by  a  typical  incremental 
development  process  since  the  various  operational  functions 
constituting  the  Navigation  and  Attack  System  are 
successively  integrated.  The  development  of  such  an 
operational  function,  which  can  be  scaled  on  the  average  to  ten 
thousand  Ada  lines,  takes  approximately  1 1  months,  as  the 
development  process  is  understood  to  encompass  the  following 
phases .  functional  definition,  global  and  detailed  design, 
coding,  unit  tests,  integration  tests,  functional  tests,  and 
validation  tests.  The  last  two  test  phases  are  executed  using 
the  target  computer  itself. 
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Software  Branches  and  Delivcrica 

The  incremental  software  development  pnKei»&  ib  concretised 
by  deliveries  of  the  entire  software.  These  deliveries  are 
normally  scheduled  at  the  rate  of  four  to  su  a  year.  On  the 
MIRAGE  2000  Export  we  made  44  deliveries  in  48  months  I!'  In 
addition,  these  deliveries  were  not  made  in  u  linear  manner. 
Indeed,  starting  from  a  common  software  development  trunk 
we  derive  what  we  call  software  branches  which  have  their  own 
specific  lives  and  are  used  to  debug  the  uperutioiiai  functions 
independently  of  the  new  developments  made  on  the  a>mmon 
trunk.  The  upgrades  made  on  the  software  integrated  on  this 
branch  are  integrated  in  parallel  on  the  common  trunk  or  are 
only  integrated  when  requested  by  the  client. 

Modifications 

Because  of  the  complexity  of  weapons  systems  and  the  large 
number  of  parties  involved  (notonly  government  agencies  and 
offices,  prime  contractors,  equipment  vendors,  butalso 
program  managers  and  pilotsi,  the  initial  dormitioii  of  an 
operational  function, and, asa  result,  everything  subsequently 
related  to  it,  undergoes  a  vast  number  of  modifications 
throughout  the  life  cycle,  even  during  the  development  phase  of 
the  function  itself.  On  the  average  five  to  seven  modifications 
are  made  each  working  day.  Here  too  the  methods  and  the  tools 
must  be  adapted  to  these  constraints. 

SOPl'WARE  DEVELOPMENT 
TECHNIQUES 

In  this  chapter  we  are  going  to  detail  the  changes  that  we  were 
led  U)  make  in  software  development  techniques  Ui  develop 
embedded  software  using  Ada 

These  evolutions  concern  the  acceptance  of  the  concept  of 
object,  the  organization  to  be  installed,  an<l  Uie  software 
programming  techniques 

Object-oriented  development 

Ada  language  oilers  various  possibilities  lor  software  quality 
and  productivity  enhancements  (data  typing,  packaging, 
generics,...).  But  these  are  useless  if  an  Ada  development  is  not 
supported  by  an  adequate  design  method. 

For  this  reason,  we  decided  to  study  and  tlien  use  001) 
techniques  having  in  mind  2  major  advantages  they  may  also 
offer : 

•  Reusability  because  of  the  better  sUibilily  of  an  object  over 
a  function,  experienced  through  diff  erent  projects  in  the 
same  application  domain  (aeronauUcsi. 

•  Prototyping  possibilities  ullowing  for  early  design 
validation  (Ada  specificatiuns  implementing  a  design 
solution  can  be  complied,  doe  to  Ada  separated 
compilation  capacity,  and  oven  ex.*€Uted  if  adequate 
"stubs**  are  added) 

Nevertheless,  potential  problems  had  u>  be  solved  before  full 
object  orientation  of  our  developments . 

•  System  constraints  through  soHware  requirements 
documents  (our  input  for  software  developments)  which 
come  from  a  functional  decomposition  process  and  thus, 
are  very  likely  not  to  match  with  object  decomposition, 
through  data  organization  for  digital  buses  exchangestthe 
way  data  are  gathered  into  messages  and  the  exchange 
conditions  of  these  messages  often  do  not  correspond  to  our 
object  decomposition  and  our  update  or  computation 
conditions). 


•  Real-time  aspects  are  most  of  the  time  not  perfectly 
handled  by  OOD  methods. 

•  Configuration  management  problems  may  arise  from  the 
large  amount  of  Ada  units  resulting  from  an  object 
oriented  decomposition  process. 

Organization 

To  allow  for  dialog  with  our  client  and  for  technical 
management  of  the  functions,  the  software  development  team 
assigned  to  the  RAFALE  project,  which  is  composed  of  more 
than  30  members  today,  is  organized  following  operational 
functions  criteria. 

However,  since  the  concept  of  object  is  taken  into  account  in  the 
software's  architecture,  it  is  necessary  to  organize  the 
interaction  between  the  diverses  parties  acting  on  these 
objects.  Thus,  a  team  member  is  assigned  to  make  sure  that 
each  object  or  group  of  objects  is  homogeneous  in  relation  to  the 
developmentof  the  various  operational  functions  using  that 
object. 

In  addition,  we  have  defined  a  dictionary  of  operational  objects, 
and  their  refinement  at  the  software  level.  This  dictionary  is 
currently  being  realized  on  an  object  oriented  database.  It  is  an 
indispensable  tool  for  facilitating  the  distribution  of 
operational  knowledge  in  the  objects  and  the  transmission  of 
information  to  all  of  the  software  development  teams.  In 
addition,  it  will  be  an  excellent  training  tool  to  discover  combat 
aircraft  software  from  operational  point  of  view  as  well  as  from 
software  architecture  point  of  view. 

Coding 

As  we  noted  at  the  beginning  of  this  paper,  the  efficiency 
quality  factor  is  primary  for  the  type  of  software  which  we  are 
interested  in.  On  the  other  hand,  Ada  offers  a  wide  range  of 
capabilities  m  terms  ofencapsulation,  data  typing,  controls, 
and  so  on. 

As  in  other  domains,  we  had  to  make  a  trade-uffbetween  Ada 
advantages  and  efficiency  We  established  Ada  programming 
rules  for  onboard  software. 

In  particular,  three  points  should  be  clarified : 

•  The  Ada  built-in  controls  are  only  used  in  the  unit  test  and 
integration  test  phases,  in  which  we  work  in  native 
language  on  a  workstation,  as  we  can  hardly  aflbrt  the 
resulting  generated  code. 

e  The  exceptions  are  only  used  in  some  very  special  cases,  as 
the  operational  software  should  have  a  well-defined 
reaction  on  a  whole  host  of  events,  even  unexpected  ones. 

•  The  generics  should  onlv  be  cautiously  used,  since  the 
advantage  of  parameterization  provided  by  them  is 
thwarted  tn  the  operational  software  by  the  generation  of 
large  amount  of  code. 

REAL-TIME  STRUCTURE  OF  EMBEDDED 
APPLICATIONS 

Ada  u  considered  to  be  weak  in  the  real-time  domain,  but  at 
the  same  time  Ada  is  one  of  the  only  languages  directly 
integrating  real-time  features. 


When  Ad«  ii  used  for  embedded  sulVwaru,  and,  thus  essenlially 
under  strong  constraints,  this  problem  has  to  be  coped  with  in  a 
global  manner  regarding  the  operational  characteristics  of  the 
application. 

Real-Time  Executive 

The  feasibility  of  using  Ada,  including  tasking,  was  one  of  our 
major  worries.  Thus,  we  developed  representative  real-time 
benchmarks  of  our  applications  in  order  to  verify  their 
feasibility  in  Ada.  We  esperimented  with  diverse  types  of 
possible  architectures  and  estal  lished  the  minimal 
speciflcations  under  which  the  real-time  esecutive  we  would 
use,  should  comply  to.  These  benchmarks  permitlod  us  to 
decide,  given  a  full  knowledge  of  the  situation,  how  to  develop 
mission  computer  software  in  full  Ada. 

The  principal  characteristic  ofour  embedded  appiications  is  the 
ability  to  respond  very  quickly  to  cyclic  external  events  (a 
recurrent  frequency  ranging  from  1  IlerUto  IGUtierUlor 
random  external  events,  along  with  the  additional 
requirement  that  all  the  events  are  assured  Ui  be  taken  into 
account.  The  processings  to  be  executed  liave  oiverse  priorities 
and  depend  on  the  response  time  or  aclivatioii  frequency.  Thu 
internal  and  external  consistency  of  the  date  handled  and  the 
associated  proceuings  are  consequently  fundamental. 

The  real-time  executive  that  we  developed  and  are  using  for 
our  applications  has  the  following  characleriatiis : 

•  It  is  compliant  to  the  Ada  Programming  luiiiguage 

reference  manual  ANSI/MIL-STO  Ibid  A. 

a  It  it  essentially  written  in  Ada,  or  in  assembly  language 
for  those  parts  linked  to  hardware  or  critical  in  terms  of 
execution  time. 

a  It  is  notapeciflc  toour  applications,  but  is  optimised  for 
our  spKiflc  needs. 

a  it  is  configurable  according  to  the  target  niachinu  to 
assure  the  portability  of  our  applications. 

a  Its  underlying  real-time  kernel  includes  a  scheduler 
compliant  to  the  Rate  Muiiolonic  Scheduling  IRMS) 
principles  in  order  to  comply  to  the  hierarchical 
structuring  of  the  tasks  of  the  applications. 

Ada  only  has  a  tingle  tynchronixationicommunication 
mechanism  called  the  reiidesvous,  which  allows  a  synchronoua 
interaction  from  n  taakato  I  task. 

There  is  m.  direct  asynchronous  mechanism  t without  blocking 
the  calling  task!  allowing  n  tasks  to  communicate  with  I  task 
or  n  tasks  with  n  tasks  in  the  Ada  programming  language. 
Writing  such  mechanisms  in  Ads  requires  the  use  of  server 
tasks,  thus  provoking  penalties  in  memory  occupation  and 
execution  time. 

Our  active  participation  in  the  RxTRA  working  group 
lExtensions  for  Real-Time  Ada)  enabled  us  hi  bo  the  aourca  of 
the  definition  of  such  mechanisms.  The  results  of  this  group 
have  been  sent  to  the  CIFO/ARTEWG.  An  effort  to  obtain  a 
convergence  between  the  ExTRA  specification  ones  is  currently 
under  way  and  is  planned  fur  the  ClPO  3.0 

To  satisfy  our  immediate  needs  and  assure  the  portabihty  of 
our  applications,  we  decided  to  implement  the  following 
mechanism ; 

a  The  asynchronous  rendezvous,  thus  permitting  a  calling 
task  nut  to  be  blocked  (SIGNAI.  and  GO  BETWEEN). 


a  The  queueing  mechanism  (BUFFER). 

a  The  eventand  pulse  mechanism  (EVENT  and  PULSE). 

These  mechanisms  are  implementable  in  Ada,  are  compUant  to 
the  Ada  rationale,  and  assure  portability.  For  our  specific 
needs,  we  optimized  them  to  cope  with  the  problem  of 
performance  by  writing  some  parts  in  assembly  language  and 
by  using  the  internal  mechanisms  of  the  real-time  kernel. 

In  order  to  promote  the  debugging  and  validation  of  software  in 
conjunction  with  the  DEVISOR  test  tool,  the  monitor  provides; 

a  A  trace  of  task  communications. 

a  The  effective  execution  time  of  each  of  the  tasks. 

a  The  storage  of  the  size  of  the  stacks  so  they  can  be 

appropriately  sized. 

Input/Output 

An  embedded  application  as  described  right  from  the 
beginning  is  strongly  serviced  by  communication  systems 
imposing  cyclic  or  random  processings  as  dsacribed  above.  The 
number  and  frequency  of  I/O  are  very  high.  Thus,  the 
communication  systems  were  designed  to  limit  the 
computational  workload  induced  in  the  application.  To  do  so,  a 
part  of  the  processings  is  handled  by  the  coupling  boards. 

The  1/0  requests  made  by  the  application  are ; 

a  Global  (several  requestaare  given  in  a  single  call). 

a  Asynchronous  (the  application  does  not  wait  for  an 
answer). 

These  actions  permitted  ua  to  reduce  the  computational 
workload  supported  by  the  application  due  to  I/O  facilities  by  a 
third. 

SOFTWARE  DEVELOPMENT  RESOURCES 

IIm  development  of  real-time  applications  under  stringent 
software  developmsnt  constrainU  such  u  described  above 
necesailates  the  availability  of  an  adapted  set  of  software 
production  tools  integrated  in  a  true  software  development 
system. 

Global  definition  and  design  tool 

STP>  (Software  Through  Picture  ‘'K)  is  the  specification  tool 
chosen  for  our  onboard  software  development  process.  8TP  is  a 
software  analysis  and  specification  environment  which  is  both 
complete  and  adaptable.  8TP  allows  the  combined  use  of 
several  modeling  techniques,  which  is  necessary  to  specify  the 
multiple  aapecte  of  a  software  system ;  structured  analysis 
(YOUROONAIEMARCO),  structured  design 
(CONSTANTINE),  structured  real-time  analysis  (HATLEY), 
entity-relationship  model  (CHEN). 

In  addition,  this  tool  integrates  the  architectural  design  phase 
in  which  we  define  our  software  architecture  (both  teal-time 
and  static  architecture),  it  supports  object-oriented  design 
method. 

Detailed  design,  coding  and  unit  testing  tools 

KEYONE^  <■»  is  a  tool  supporting  the  detailed  design  and 
coding  phases  (since  it  haaa  syntax  editor).  In  addition,  it 
allows  one  to  produce  a  standardixed  documentation. 
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A  set  of consistent  translators!  Ada-AI^SYSsyiitem,  assembler) 
allows  one  to  construct  an  application  from  modules  written  in 
diverse  languages. 

DEVISOR^^^  is  a  software  debug  and  test  system  covering  all 
of  the  test  phases  both  static  (execution  not  in  real-ttme)  and 
dynamic.  Its  principal  characteristics  are : 

•  The  tested  software  is  not  disturbed. 

•  The  testis  formalized  and  automated,  for  easy  non- 
regression  testing  thanks  to  a  high-level  language. 

•  Independance  is  assured  between  languages  and  tai^et 
machines. 

•  The  man/machine  interface  is  user  friendly  and  extended 
use  of  symbolism  is  made. 

•  The  test  program  may  bo  autumalically  generated. 

DE  VISOR^*^>  operates  in  a  static  configuration  on  a  host 
machine  (UNIX-based  workstation) 

Validation  Tools 

UEVISOR^^*  operates  in  a  dynamic  configuration  connected  to 
a  real  target  machine  through  a  logic  analyzer.  Thus,  it  is  used 
for  the  software  integration  phases  in  which  the  software  is 
integrated  in  the  target  computer  and  the  real-time 
architecture  is  validated. 

The  SVli  (Software  Validation  Bench)  is  used  to  validate  an 
operational  software.  It  simulates  the  computer  environment 
(i.e.  all  the  equipments  connected  U)  the  computer  m  the 
embedded  system)  while  complying  to  real-time  and  data 
consistency  aspects  and  allows  for  setting  those  slates  difficult 
to  obtain  with  real  equipment  (failures,  transmission  errors, 
etc...).  The  principal  ^nctionalities  are  the  simulation  of  the 
environment,  the  graphical  display  of  the  behavior  of  the 
software  to  be  validated,  the  control  of  the  target  computer,  the 
automation  of  test  procedures  for  nun-regression. 

Need  for  an  integrated  software  development 
environment 

In  addition  to  the  tool  aet  that  we  were  forced  Ui  develop  in  part, 
a  true  aoflware  development  environment  in  which  three  toola 
are  integrated  alao  was  indiapensabl'j. 

Thus,  we  developed  IUADIi2,  which  oilera  the  I'uliowing  three 
runclionalitlea : 

•  A  confifuration  manager,  which  contrula  and  munagea  all 
of  the  objecta  involved  in  the  aotlware  development  cycle, 
that  la,  the  documentation  (apecincatiuiia,  deaign,  teat 
niea,  ate...),  the  code  (aource,  binary,  Ada  librariea,  etc...I, 
the  teat  object  (aheeta,  data,  progranu,  reaulta,  eU:...land 
documenta  axchanged  between  a  pi  ime  coiitracUir  and  a 
aub-contractor. 

•  A  production  manager,  which  automatea  the  production 
not  only  of  the  Ada  aoKware,  but  alau  the  documentation, 
test,  and  ao  on.  Thia  function  alao  controla  and  managea 
the  aoftware  production  aervera  and  their  resuurcea  m  a 
way  transparent  to  the  user. 

•  A  methodological  support,  which  aaaiata  the  wiflware 
devtlopment  teama,  prpject  managers,  or  buaineaa 
ixacutivea  assuring  a  presentation  and  a  roethodotogical 
tracking  and  follow-up  proceaaof  the  project  through  an 
adequate  synthesis  level. 


ILIA1)E2  is  a  parameterizable  tool,  especially  regarding 
methodological  support,  and  an  open  tool  as  well,  since  it  allows 
the  integration  of  new  tools. 

CONCLUSION :  "USING  Ada  7" 

In  conclusion,  we  sre  going  to  conclude  about  the  experience  we 
have  acquired  using  Ada,  lint  in  terms  of  productivity,  and 
then  on  more  general  aapects. 

Ada  and  productivity 

As  we  have  been  developing  embedded  software,  we  have 
esperienced  a  gain  in  productivity  of  approximately  30  percent, 
since  the  development  of  a  ftinclion  given  i  |ual  functionality 
demands  an  elTort  of  about  30  percent  leas. 

However,  in  addition  to  this  gain  in  productivity,  we  observed  a 
aignilicant  increase  in  time  for  the  architectural  design  phase. 
We  also  observed  the  following  distribution  of  the  effort  needed 
by  the  diverse  software  development  phases : 

•  1 0  percent  for  the  functional  specifleation  phase. 

•  30  percent  for  the  architectural  deaign  phaaa. 

•  30  percent  for  the  detailed  deaign,  coding,  and  unit  test 
phases. 

a  30  percent  for  the  software  integration,  hinctional,  and 

global  validation  teals. 

Ada :  auccets  or  failure  7 

We  have  seen  that  the  development  of  embedded  software  and 
the  embedded  software  itself  sre  subject  to  a  whole  host  of 
constramla  and  requiremenle.  At  the  tame  time  the  lH>^ware 
must  be  secure  and  have  the  loweat  failure  rate  pouible.  In 
addition,  considering  the  evolutionary  trend  m  technology, 
portability  is  a  key  factor  for  long  life-cycle  software. 

All  of  these  factors  when  combined  are  favorable  or 
unfavorable  for  tho  Ada  programming  language,  which, 
besidea  the  coding  aapecls,  impact  on  all  of  the  software 
development  phases. 

In  light  of  the  experience  we  have  acquired  with  Ada,  it  Is 
mandatory  that  all  of  the  components  characterising  embedded 
software  be  controlled  and  managed  correctly.  That  is : 

a  The  software  development  msthoda  and  the  way  of  uaing 
Ada  to  conserve  indiapenaable  efliciency. 

a  The  real-time  aipecta  while  waiting  r-ir  future  extenaiont. 

a  The  aoftware  development  resources  to  an  ure 

productivity. 

Only  by  complying  to  these  conditions  will  the  development  of 
embedded  software  for  combat  aircraft  written  in  Ada  prove  to 
be  aucceaaful. 


1  STP  is  a  trademark  of  INTERACTIVE  DEVELOPMENT 
ENVIRONMENTS. 

2  KEVONEia  a  regiatered  trademark  of  LP6. 

3  DEVISOR  ia  a  regiatered  trademark  of  DASSAULT 
ELECTRONIQUE. 
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SUMMARY 

In  the  Add  of  hdicopter  flight  control  and  tiaadUng  qualit 
potential  beoeflii  offered  Iw  Active  Control  Technw^  are 
conaidetable.  To  import  the  devdopment  of  appropriate 
haodlittg  criteria  and  carefree  manoeuvring  featwei,  the  UK 
Royal  AewipnceEitabllihmenthai  been  engaged  In  die 
development  of  an  ACT  lyitem  for  a  teaeaich  Lynx.  Af 


actuation  and  fUi-opemte/fUI-eafe  hardware  architecture.  The 
impact  of  the  requited  fttnedondity  on  the  eyMem  requltemenis 
dictated  a  need  for  a  predie  yet  vetndle  ipMiflcation  of  the 
lyitem,  and  Jackion  System  Devdopmeot  (JSD)  wae  lelected 
u  a  design  method  lince  it  providee  a  fotmd  modelling  of  the 
pilot  interface,  and  also  operatm  at  a  sufficient  levd  of  detail 
neceesary  to  ensure  completeness  and  reaotudoo  of  ambiguities. 
The  tools  which  support  JSD  indude  automadc  code  genenuion, 
and  for  this  wotfc  wete  flitdier  developed  to  accommodate 
changea  to  syatem  architecture  in  an  efficient  manner.  Thecode 
ptodoced  provldea  a  dlteet  ihnulatiou  of  the  design  and  results 
in  a  living  ipedfloulon  available  for  valldsdon  aA  tnvestigation 
of  the  written  spedfleadon. 

1.  INTRODUCTION 

In-flight  dmulatlon  provides  the  ultimate  vaUdsUon  test  of  a  new 
fh^t  control  concept.  The  tedlsm  of  fli^  test  oveicomes  the 
dendeneesofgtound  baaed  simulation  aseocliled  with  cue 
flddltyandmoddllaginaccutades.  On  the  other  hand,  cost  and 
safety  issues  coostrahi  what  Is  achievable  in  emerimental  flight 


control  and  hrmdlltm  qualities,  the  potential  benefits  offersd  by 
Active  Control  Tectaoiagy  (ACT)  ate  ooneldtcabte  { 1  ]  and 
results  derived  from  ground  and  In-fUaht  afaaulation  In  Europe 
and  North  America  Mve  dsmoMtssied  benefits  at  moderate 
performance  levels,  ntiuremiliiswtolorcraft  will  need  to 
operate  at  coosUsmMy  higher  aerioimrmoe  and  ittlaugher 
environmeols  than  currently  aodeviMe.  To  support  the 
development  of  approprfale  handUng  criteiia,  oareAee 
mMBOWvfiiM  CNitMWi  Md  ndvioki^iit  is 

controls  aaddhiplaya,  a  tataAer  of  lessarchlsberstorles  are 


LynxUsS).  fMimof* 

include fhUauthofityftrbywfre(I«W)actualioa,  aafetypllot 
with  back-driven  eonirols,  litU-operale/iUl-safe  (FOPS) 
hardware  ardriteesure  eoqplad  to  a  range  of  novel  ssaaota  and 
pilot  hicepioiaptovidiafl  inputs  to  the  cantrol  laws.  TheFOFS 
Afdiiiwittii  it  fvoMMd  iwUt  Mli  dpfrinMld  lUilii  is  ^ 
nap  of  earth  and  at  the  edges  of  die  petfntiasnct  envelope.  The 
iminct  olidt  ftnctiottll^  (M  Af 
rrqirirmisnti  Is  cnaaldcsslile  RAEUeaiUledanaedfora 
pt^,  yet  veandfespetlflwtieaofihe  system  to  pcrftum 
these  flMctlooa  developed  dkreiigh  design  and  validated  through 
shnulailon. 

The  spedflemion  ttseded  to  address  flmctiaaality  ((be  both 
oosaasl  and  fidled  states),  operation  ard  pesibenisnoe  of  the 


teer&teqwremeata.  The  apedflcalianalao  needed  to  be  fit  for 
ratrdiHditngteallitlcdeveloprnent  costs  and  thBretsdos,  The 
approach  taken  has  crystaHied  into  two  phases.  Fiistly,the 
devdopmeatofa  textual  dcecslplioo  of  the  ayatsaswidi 
accompanying  Uhntratioos.  During  this  activity,  a  mimbef  of 


dlfTerent  methods  were  applied  by  (Sflerent  team  membeta  in  an 
attempt  to  fotmaHse  the  requirements,  to  tackle  design  is^ 
and  to  provide  a  foimat  compatible  widi  die  hnet  stages  of  m 
syatem  life  cycle.  The  Jackson  System  Development  (JSD) 
methodology  was  sdected  for  several  reasons: 

(rO  The  JSD  modelling  products  a  formal  spedfleadon  of  all 
the  pilotAystem  InteiBcdon  and  so  forces  the  engioeer  to 
consider  system  behaviour  from  a  consttuctionaVdesIgn 
tather  than  hierarchical  description  viewpolnL 

(b)  The  JSD  network  provides  a  complete  description  of  all 
the  external  system  Interfhces  requited,  plus  a  systematic 
perddoning  of  die  system  Ibncdonallty. 

(c)  AmUguldca  in  die  texntal  material  ate  nanitally 
idendfled. 

(d)  Tools  were  available  to  support  the  mediod  Including 
automatic  code  generation. 

A  most  irnportant  fsalute  of  the  rpedfleaden  is  dtat  it  Is  an 
executaUe  version  of  the  flmedoM  bchsfvlourof  the  system. 
Ada  code  la  automadcelly  generated  ftesn  the  spedfleadon  and, 
when  combined  widi  a  sbnulation  of  the  flight-model  and 
various  periphetal  dsviesa,  becomes  a  living’ qredfleadon  of 
the  system  behaviour. 
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nguie  1  ACT  Lynx  System  Elements 

The  second  dssa  of  tequitesnem  invoivet  fee  iaveadgadon  of 
options  for  dM  exact  nadtre  of  the  flatd  system  impMaeasaiion. 
TUaieesardiiaiatitaaielyooniaeciedwImdmauMiet  aad  types 
of  processing  clement,  and  the  fbim  of  fiaik  moaUociag  and 
rwordt^.  Todds endaaewlsepnyhM been  Invented  wMdt 
allows  desctipiioo  hardware  layouto  and  fee  pcovisioa  of  fink 
tolerance.  The  deect^xkMlaiqpir^  is  sapported  by  data  entry 
and  code  geaetadoo  took  feat  allow  maddae  manipobiloo  of  fee 
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deicriplioa  and  lolitdOD  of  Ae  tpedSed  qMem  tidag  Ada. 

TUt  ftcOity  eaaUes  dK  invcaliaadoa  of  VMiou  lacdim 
aidiiiectuie*,  provitfiiig  Ae  ^tal  icaHam  miiilfed  to  back  ap 
more  coacqKual  Rseam 

TUi  pqiet  detcribea  the  development  of  Ac  ACT  Lynx 
require^t  sped&calioa,  dn<^  00  a^jecii  of  the  ayMem 
{iiMooaUty  to  iDuUtale  Ac  ISD  apptoach  of  modelH^  and 
netwoik  analysit.  Sectioa  2  coven  Ae  evohtiloo  of  the  ACT 
Lynx  lequiiementt  tcaAng  to  the  need  for  a  pmotype 
Emulation.  Sections  3  and  4  deal  edA  the  ^elopmeat  and  tiae 
of  the  Ada  aimolalioo,  iOuatiating  Its  faiveitlgalivepoteotial. 
Section  3  Aacusaes  the  way  fonward  for  Ae  apedficatioo  and  the 
pKiiectaaawhole. 


This  paper  is  the  second  in  a  aeries  aimed  at  pravidinf  grader 
via{bil%  on  Ae  qipioach  befam  taken  by  RA£  for  Ae  ACT  Lynx 
pn^ect  The  flfst  covered  Ae  HA  gicleefaoaotrol  law  (4|, 
fioffi  concepdon  to  fib ' 
and  proposing  a  new  e 


e  that  enhances  the  kaowb 
n^reprooM  while  encdfing  flight  safety.  FUidierpapenare 
planned  ttat  will  look  at  the  p^ormanoe  venaw  safety  tiade-ofli 
In  the  fU^tdcaiance  of  advanced  heiloopttrfll^oMmoliaws 
and  aoftim  verification  aapeeta  prior  to  Implenientatlon  A  the 
airborne  ayatem. 


2.  EVOLUnON  OF  THE  SPECIFICATION 


2.1  Background 

In  a  serlea  of  technical  memoranda  and  reports  [2, 3, 3,6]  RAE 
devetraedtheiationaleferaptomunmeor  leseaich  hasedon 
an  ACT  helicopter.  Further  atumes  have  demomirated  Ae 
pratcdcal  fcadbllity  of  ntodif^iy  the  RAE  AH7  ij^x  ZD  339 
Into  a  Hill  author!^  ACT  vehicle  for  audi  a  puipoae;  eneouia^ 
by  the  feasibility  of  Ab  approach,  RAE  emhaiud  on  Ae 
preparatloo  of  a  apeciflcatioo  for  tire  alihome  ayatem  ( Aiihome 
System  Requirements  Snecifloadon)  of  dm  act  Lynx 
piDgiamme.  Figure  1  ilMstrales  the  design  concept  wAere  Ae 
experimental  pflot’a  convendonal  control  rune  ate  replaced  wiA 
an  ACTsyatm.  The  elementaiy  modules  ofthenaw  system 
are  doKribed  more  fidly  below,  A  section  2.3,  hut,  in  essence,  a 
flight  control  computer,  wiA  corresponding  Aterface  units, 
connects  a  new  set  of  Incurs  and  rensori  to  a  group  of 
parallel  actoatots  driving  the  oiWnal  actuation  system.  From 
the  outset  RAE  were  deieimlnedthat  Ae  specification  ihouU  be 
the  basis  of  a  well  managed  procurement  exercise,  and  as  such, 
should  solve  all  of  the  simllKant  design  isiuce  of  the  system. 
Poternial  auppllere  would  then  he  abk  to  asicas  accurately  the 
costs  of  sueplying  the  various  components  of  the  system,  since 
the  possAiltlv  of  being  involved  in  expensive  open  coded  desi|n 
wont  would  be  elimlniued.  Also,  by  sotvlng  Ae  outstanding 
design  problems  ah  lallh,  RAE  would  be  sure  that  the  system 
could  actoally  be  supplied  A  accordance  wiA  the  speciflcatioo. 


As  a  mauerof  ddibemiepolicy  die  dc^  team  at  RAE  took 
Issue  2.0  and  auli]ecttd  it  to  caceftlscmAy  to  order  to  identify 
dioee  areas  where  it  could  he  dgniflcandyinqiroved.  In 
particular,  die  possibility  of  uatogJSD  was  te.examtoed  since  to 
dto  context  of  Ac  ACT  Lynx  appUcation  a  mediodoiogy  biased 
towards  qntem  developmeni  was  consideted  to  he  more 
appropriate  ihaaadeeonipodtiooat,hietariAical,deKttottve 
technique.  AstrengAofdieJackaonmediodisdiatitqiensdie 
full  mage  of  activity  from  system  definition  to  production  of 
code  [  1 1 1,  so  diat  at  one  end  it  is  ooDcemed  WiA  modell Ag 
correcdy,  for  example,  the  actions  of  the  pilot  when  he  uses  the 
Pilots  (^ttol  Panel  (shown  in  Fig  2  and  discussed  fiilty  to 
section  2.3,bdow)  and  at  the  other  end  contains  the  level  of 
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2.2  Adoption  of  lackaon  Techniquca 

WiA  the  objective  of  producing  a  complete,  unambiguous 
speciflcatiott  it  was  decided  to  employ,  as  fat  aa  Msslble,  the 
tedinkiuea  of  Software  Eogtoeettog,  The  diacipUnes  of  these 
techniques  would  ensure  a  rigorous  devdopnicnt  of  the  design, 
and  Ae  associated  CASE  tools  would  assist  to  ntalntatolng  the 
pttcisioo  and  totagrity  of  die  npedllcatiaa.  For  the  dUtal  part  of 
the  total  system,  me  methods  could  be  applied  dfreeny  butfor 
other  parts,  which  could  Include  analogue,  mechardcal, 
hvdwstlic  and  even  human  compotstats.  It  was  not  immediately 
clear  how  the  software  technlquoi  could  he  adapted.  Moreover, 
itwaadedrableAat,  at  the  spedllcailoo  stage,  there  should  be 
some  freedom  as  to  die  type  of  Implemeaiation  uWaaaldy  chosen 
-  leaving  open,  for  examine,  die  option  of  dissimilar 
Implrmiratotlona  of  irdundant  uolla.  lackaon  System 
Devdopmeat  (ISD) ,  (7,8]  was  atipuhMedaa  die  preferred 
methodolagy,  but  proved,  at  leant  toMatly,  to  be  (RfBcult  to 
embiace  to  dds  novel  ctipiext.  While  dMAIBcuiticarelsttog  to 
dteuaeofJSD  were  befcu;  resolved,  Acre  was  a  partial 
application  of  De  Mmeoff]  arediodi;  cowerpteady,  when  Ae 
lint  vcialon  (Issue  2.0  (10])  of  die  apedflcsaloo  was  dreubted 
Mnoatotup|illeis,laaddRiontoAe  conveadoonlatiuctuteof 
paiagnphsoflext  aiipplemeotedbyaaeloftediiiad 
ittustCTtioi>sanddiagianis,ltcootaliiedagwsipofdaiaflow 
dtograma  and  data  conpotitiona  lelatiiigtoaDeMarcastjde 
enMncement  to  the  text 


detailed  speeification  aeceasary  to  generate  eode.  Such  a  level  of 
detail  enauraa  that  the  deaigu  meUm  of  the  apedfleatien  have 
been  addressed  even  if  the  software  is  not  aetoidly  produced,  but 
In  Ala  t^ppUcadon  a  ftiidier  Men  has  been  taken  and  code 
produced  to  Implenieot  a  idmwaiion  of  die  spedflcd  system  of 
issue  3.0  (section  4).  These  two  areas  had  not  been  i^en 
sulTIcieat  emphasis  in  the  De  Marco  work,  and  die  dheipitoe  of 
ISD  would  force  attention  to  them. 

2.3  Spedflcation  structure. 

It  wm  also  felt  nectaaiy  to  adopt  a  modifled  ttnidure  for  the 
apedfleationinorderte  give  R  more  cohedon.  The  new 
structute  dateribed  the  sjutem  to  tenna  of  its  maior  Aoctioaai 
elcmcaii.  TUa  decomposition  was  die  only  one  that  was 
impoaed  on  dto  ayatem  a  wiorf  and  reflected  aaepniatioowfatch 
was  unavoidably  tooitred  by  the  aabre  of  the  project  Such  a 
subdivision  does  not  prechide  further  subAviatooa  should  they 
evolve  from  Ae  deaiga  process.  The  outcome  is  shown  to 
Figures,  where  die  rcctangidarcampancma  are  those  rdevant 
to  Ae  tpedfleadott  exerdae.  The  bold  KCtsaglm  are  reftrred  to 
as  prooeasiag  dements  aad  would  togethar  form  a  FHght 
Control  Canqaitets  alAoo^  audi  lenatoolagy  was  aot  used  to 
die  speciflcatioo. 

The  demetts  of  die  ayatem  uc  deaciAed  in  Ae  order  of  the 
pttouuyflow  ofdiedgntltoformatioe: 


21-3 


(i)  Sensor  Element  (SE).  This  leading  element  contains  the 
aircraft  motion  sensors  -  attitude  and  rate  gyros  and 
accelerometers,  and  also  the  air  data  units  for  obtaining 
velocity,  pressure  and  temperature  information. 

(ii)  Crew  SUition  Element  (CSE).  The  other  leading  element 
incorporates  (he  conventional  controls  for  the  safety  pilot  and 
a  versatile  side  arm  controller  facility  for  (he  experimental  or 
evaluation  pilot.  The  CSE  also  contains  the  various 
interfaces  for  (he  pilot  to  engage,  operate  and  be  cued  by  the 
ACT  system.  Figure  2.  as  lollows: 

(a)  Pilots  Control  Panel  (PCP)  •  used  by  (he  Experimental 
Pilot  for  engagement  and  disengagement  and  also  for 
conducting  the  system-test  sequence. 

(b)  Repeater  Panel  (RP)  -  provides  a  copy  of  the  displays  for 
the  Safety  Pilot. 

(c)  Menu  Panel  (MP)  •  provides  other  ACT  interactions, 
such  as  selecting  one  of  the  avaiiable  control  laws  and  sets  of 
parameter  values.  The  same  panel  provides  the  interface  for 
injecting  preprogrammed  disturbances  into  the  system,  as 
part  of  a  Right-test  facility  used,  for  example,  in  (he 
validation  of  the  helicopter  mathematical  models  and  in 
demonstrating  compliance  with  handling  qualities 
requirements  of  new  control  laws. 

(d)  Mode  Select  Panel  (MSP)  -  available  for  in-flight 
selection  of  control  modes. 

Clearly  the  CSE  would  be  expected  to  feature  signifleantiy  in 
any  JSD  modelling  exercise,  with  the  pilot  assuming  a 
number  of  different  roles  as  he  interacts  with  diflercnl 
components  of  the  system.  Some  of  the  related  modelling 
issues  are  discussed  in  section  2.5,  below. 

(iii)  Control  taw  Input  Support  Element  (CLISE).  The 
following  element  has  the  main  purpose  of  processing  and 
managing  the  infoimation  from  the  Crew  Station  and  Sensor 
Elements.  It  also  contains  the  scheduling  of  a 
comprehensive  system  test. 


(iv)  Control  Law  Element  (CLE).  This  next  element  is  supplied 
with  inceptor,  .sensor,  mode  selection  and  related 
information  by  the  CLISE.  The  CLE  is  the  raison  d'etre  of 
the  ACT  Lynx  since  it  hosts  (he  experimental  control  laws 
which  arc  to  be  evaluated.  It  is  this  element  that  the  user  of 
the  ACT  Lynx,  the  handing  qualities  engineer  or  flight 
dynamicist,  will  interact  with.  Carefully  verified  and 
validated  control  law  software  |4]  will  be  plugged  into  and 
unplugged  from  this  element.  Typically  six  control  laws  will 
be  selectable  by  the  experimentril  pilot  with  an  additional 
choice  of  up  to  six  sets  of  parameters  within  each  law.  The 
demands  produced  by  the  CLE  for  each  of  the  four  axes  may 
be  separated  into  low  and  high  frequency  demands,  if 
required,  which  arc  destined  for  the  parallel  and  series 
actuators  respectively  (An  option  being  currently  evaluated). 
The  separation  algorithm  is  part  of  the  user  supplied  CLE 
software. 

(v)  Control  Law  Ouqnrt  Support  Element  (CLOSE).  The  element 
following  the  CLE  interfaces  the  demands  produced  by  the 
Control  Law  Element  to  the  remainder  of  the  system.  It  also 
provides  a  selectable  limiter  on  the  rates  and  demands 
produced  by  the  control  law  as  additional  protection  against 
immature  soflwarc. 

(vi)  Actua'or  Drive  and  Monitoring  Element  (ADME).  The  final 
element  to  provide  processing  takes  the  demands  from  the 
CLOSE  and  produces  drive  signals  for  the  parallel  ectuators 
resident  in  the  Actuator  Element,  and  the  series  actuators  in 
the  Primary  Fiight  Control  Units  (PFCU).  The  ADME  also 
manages  the  engagement  of  the  ACT  system  through  (he 
energising  of  the  parallel  actuators,  and  supplies  a  normal 
autos’abilisation  function  when  the  ACT  system  is  not 
engaged. 

(vii)  Actuator  Element.  The  parallel  actuator  system  is  last  in  the 
sequence.  When  engaged,  it  drives  the  existing  Lynx 
PFCUs.  The  parallel  actuators  are  connected  to  the 
conventional  control  runs  from  the  safety  pilot,  so  that  when 
the  acniators  are  engaged,  the  controls  are  back  driven  to 
provide  the  safety  pilot  with  essential  control  position  cues 
and  to  aid  in  recoveries. 
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(nil)  External  System  Support  Element  (ESSE).  In  support  of 
this  network  of  elements  is  an  element  which  essentiaily 
provides  a  catchment  for  ail  of  the  significant  data  in  the 
system.  It  interfaces  with  the  standard  data  acquisition 
system  MODAS  [12]  and  also  with  the  experimental  displays 
such  as  helmet  mounted  or  head  down  d  splays.  A  record  of 
all  system  related  events  such  as  engagement, 
disengagement,  and  diagnostic  messages  is  retained  in  a 
System  Journal. 


2.4  Element  descriptions. 

Issue  3.0  of  the  specification  contains  a  detailed  description  of 
each  of  the  elements  identified  above.  As  far  as  possible,  the 
recommendations  of  the  STARTS  [13]  guide  have  been 
followed  in  the  preparation  of  Issue  3.0  [  14).  Each  element  is 
described  in  detail  under  the  headings  Type,  Function, 
Operation,  Performance,  Inputs  &  Outputs,  Interfaces,  Testing, 
and  Failure  Reporting  &  Recovery.  Where  a  particular  clement 
is  composed  of  replicated  units,  so  that  sever^  units  together 
comprise  an  element,  the  replication  of  units  in  the  element  is 
stated  and  the  unit  itself  is  described  under  the  same  headings. 
For  example,  the  CLISE  Is  a  triplex  element  composed  of  three 
identical  CLISOs  (Control  Law  Input  Support  Units).  In  detail 
the  descriptions  are: 

TYPE  •  Some  Indication  is  given  here  of  whether 
implementation  is  anticipated  as  an  analogue,  digital, 
mechanical,  hydraulic,  electro-mechanical  or  human  process. 
The  suggested  implementation  is  not  intended  to  exclude 
alternatives  if  a  supplier  possesses  a  particular  specialism  The 
view  was  taken,  afler  some  deliberation,  that  it  was  better  to 
make  specific  recommendations  rather  than  to  leave  the  'type' 
issue  open.  A  general  allowance  could  then  be  allowed  for 
variations  that  nevertheless  complied  with  the  functions’  aspects 
of  thespedficalicn. 

FUNCTION  •  Utider  this  heading  is  a  complete  statement  of  the 
tasks  of  the  unit ,  that  is,a  statement  of  what  the  unit  has  to  do. 
For  example,  one  of  the  tasks  of  the  CLU  (a  unit  of  the  CLISE) 
is  inceptor  management;  the  enity  reads:  ’'The  inceptor 
displacements  and  inceptor  switch  positions  shall  be  processed 
to  provide  consolidated  signals  for  the  associated  Control  Law 
Unit  (CLU)" 

OPERATION  -  This  sub-section  is  concerned  with  how  the  unit 
wiil  achieve  its  functions.  This  is  done  by  detailed  description, 
in  text,  of  the  proccssini,  equired  for  each  function.  Forthe 
CLISE  example  above,  the  full  details  of  the  processing  of  the 
triplex  signals  would  be  supplied.  Including  the  consolidation 
algorithms  for  fault  tolerance.  The  narrative  under  this  heading  is 
used  to  build  the  ISO  Specification;  the  full  JSD  is  not  he’d 
within  the  text  of  Issue  3.0,  but  suflicient  initial  design  work 
was  undertaken  to  be  confident  that  a  JSD  specification  could  be 
derived  from  the  narrative. 

PERFORMANCE  -  A  statement  of  the  times  within  which  the 
tasks  must  be  completed  and,  where  appropriate,  the  accuracy 
that  must  be  achieved.  For  example,  a  certain  part  of  the  system 
lest  must  be  peifomied  within  a  stipulated  lime  The  sampling 
rales  for  the  unit  would  be  specified  here.  A  defined  constraint  is 
tlwl  the  total  system  transport  delay  should  be  25  ms. 

INPUTS  &  OUTPUTS  -  A  list  ofali  signals  received  by  the  unit 
and  those  transmitted  by  it.  It  includes  the  source  of  a  received 
signal  and  the  destination  of  a  liansmilled  one.  This  information 
is  also  presented  in  diagrammatic  form,  Figure  4,  for  example, 
where  the  connections  to  neighbouring  units  are  clearly  visible 
(The  network  notation  is  discussed  in  section  3).  There  is,  of 
course,  a  need  to  maintain  consistency  here,  since  for  each  input 
listed  there  must  be  a  corresponding  output  on  some  other  unit 
Such  consistency  is  easily  maintained  by  a  CASE  tool  such  as 
Jackson  Work  Bench  [15]. 

INTERFACES  ■  A  iisi  of  the  units  and  their  types,  both  internal 
and  external,  to  which  the  subject  unit  is  connected.  The 
purpose  of  this  information  is  to  identify  the  interfacing 
requircmenis  between  units  -  analogue  to  digital,  for  example. 

fES  flNG  -  A  statement  of  how  the  function,  operation  and 
performance  of  the  unit  is  verified.  In  particular  this  may  be 


Figure  4  Connections  to  a  CLISU 

done  at  a  system  lest  invoked  prior  to  take  off,  or  by  the  inbuilt 
monitoring. 

FAILURE  REPORTING  AND  RECOVERY-  A  statement  of 
how  errors,  produced  by  a  fault,  having  been  delected  are 
rolled  within  the  system.  Usually  they  are  reported  to  the  oilot 
via  the  Menu  Panel,  and  they  are  also  sent  to  the  system  journal 
part  of  the  ESSE.  Cautions  and  Warnings  may  also  be  raised 
through  the  Central  Warning  System.  In  addition,  a  statement  of 
the  recovery  of  the  system  may  be  required,  often  this  is  by 
reluming  to  Standby  via  a  controlled  disengage  -  as  would  be  the 
case  when  one  of  the  monitoring  tolerances  within  the  system 
has  been  exceeded. 


Once  Issue  3.0  of  the  airborne  system  specification  was 
complete,  it  was  decided  to  progress  to  a  full  JSD  specification 
in  Older  to  check  out  any  residual  ambiguity,  vagueness  or  plain 
error.  The  full  JSD  would  then  be  available  to  use  as  an  adjunct 
to  the  written  specification.  It  would  give  a  precise  description 
of  the  interfaces  between  the  components  of  the  system  and 
between  the  system  and  any  external  devices,  to  the  benefit  of 
prospective  suppliers. 

A  further  decision  was  made  to  use  the  JSD  to  generate  a 
simulalicn  of  the  ACT  system,  to  produce,  in  efficl,  a  living 
specification  which  could  be  used  to  exercise  and  examine  the 
specification  dynamically.  The  novei  features  involved  in  this 
step  are  described.  In  detail  In  section  3,  but  the  six  aims  of  the 
simulation  in  relation  to  authenticating  and  potentially  enhancing 
the  specification  were; 

(i)  Control  and  human  operation  of  the  system.  Pilot  evaluation 
of  the  procedures  for  operating  the  system,  for  example,  the 
arm/engagt/disengage  sequence  can  be  evaluated  through 
hands  on  experience.  Also  suppliers  can  directly  examine  the 
nature  of  the  interface  between  their  equipment  and  the  rest 
of  the  system. 

(ii)  Synchronised  control  information.  The  techniques  for 
managing  and  synchronising  control  information  within  an 
asynchronous  system  can  be  verified. 

(ill)  Establishing  tolerances.  An  asynchronous  system  generally 
must  allow  some  tolerance  in  the  monitoring  of  the 
information  from  replicated  units.  Suitable  tolerances  can  be 
verified  or  even  deduced. 

(iv)  Computational  load.  The  processor  power  and  memory 
requirements  of  the  system  can  be  more  confidently  deduced 
from  a  simulation  than  a  specification.  Alternative 
implementations  may  be  evaluated  for  processing  efficiency. 

(v)  Fault  management.  The  mechanisms  for  reconfiguration, 
and  the  issuing  of  caution  and  warning  signals  may  be 
verified  directly. 

(vi)  Design  Evolution.  Alternative  designs  for  the  components  of 
the  system  can  be  evaluated  directly . 


Before  leaving  this  discussion  on  the  evolution  of  the 
specification  in  order  to  consider  the  development  of  the 
simulation  in  detail,  there  are  two  topics  worthy  of  a  special 
note. 
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2.5  The  Supervisor  as  a  modelling  issue. 

One  area  which,  from  the  beginning,  was  subject  to  intense 
scrutiny  was  the  control  or  overall  supervision  of  the  ACT 
system,  including  engagement  and  disengagement.  Clearly  this 
is  a  critical  area  where  it  is  essential  to  get  the  specification  and 
implementation  correct.  An  example  of  an  early  model  is  shown 
as  the  flow  chart  in  Figure  5,  where  the  System  Test,  initiated  by 
the  pilot,  if  successful,  is  followed  by  a  repetition  of  the  ann, 
engage,  disengage  sequence  of  actions.  While  useful  for 
conveying  the  general  idea  of  the  pilofs  interaction  in  this  area, 
it  was  not  sufficiently  precise  to  base  soflware  directly  upon. 


Figure  5  Possible  System  Control  Flowchart 


For  example,  it  is  possible  in  the  specification,  to  return  to 
Standby  through  a  disengage  action  without  an  engagement  of 
the  system.  This  path  i.»  not  shown  in  the  flow  chart.  To 
express  the  requirements  in  a  precise  manner  finite  state 
machines  (FSM)  were  mooted  and  proved  a  very  useful 
appixrach.  That  shown  in  Figure  6  Included  the  additional 
transitions  to  Standby  omitted  from  the  flowchart,  but  suffered 
from  a  shared  disadvantage  that  the  system  test,  itself.  Included 
arm,  engage,  disengage  sequences.  FSMs  have  the  advantage 
that  they  are  readily  Iraiufomred  into  software  so  they  were 
seriously  consider^  as  a  basis  for  a  'supervisor'  process,  which 
would  have  overall  control  and  only  permit  allowed  transitions 
of  the  system  to  occur.  The  problems  experienced  wilh  this 
approach  were  twofold.  First,  incorporating  all  of  the  possible 
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states  and  transitions  afforded  by  the  pilot  resulted  in  a  very 
complex  FSM,  which  was  difficult  to  interpret  and  militated 
against  a  correct  implementation.  Secondly,  the  engage  or 
disengage  actions  made  within  system  test,  gave  different  states 
from  those  occurring  after  a  successful  system  test. 
Conseqfuently,  and  very  importantly,  the  system  test  did  not 
exercise  that  part  of  the  controlling  software  which  would 
ultimately  be  used. 


These  problems  were  resolved  in  the  final  JSD  modelling,  part 
of  which  is  shown  in  strocture  diagram  form  in  Figure  7  where 
the  system  test  and  engage  models  are  separately  treated  but  have 
appropriate  interlocks.  In  the  stnicnire  diagram  notation,  which 
is  described  more  fully  in  section  3,  the  leaves  of  the  tree 
stnicmre  are  actions  (similar  to  transitions  of  the  FSM)  and  in 
Figure  7  there  is  a  repetition,  denoted  by  the  symbol,  of  the 
alternatives,  denoted  by  the  'O’  symbol,  of  a  normal  engagement 
cycle  or  an  early  disengage.  The  Arm,Atmed,  Engage  sequence 
can  be  quitted,  denoted  by  the  ’!'  symbol,  at  any  stage  to 
continue  with  an  early  disengage.  The  system  test  process  is  a 
simple  cycle  of  alternatives  of  a  successful  or  unsuccessful  test. 

The  exa.-np1e  above  has  been  discussed,  for  clarity,  in  a 
simplified  context,  omitting  such  complications  as  control  law 
selection  and  dismibance  injection,  but  the  same  principles 
apply.  The  use  of  JSD  in  this  area  helped  to  achieve  a 
satisfactory  modelling  and,  further,  the  model  can  be  directly 
implemented  as  a  process,  upon  which  the  whole  of  the  software 
can  begin  to  be  constmeted.  It  is  also  interesting  to  note  that  the 
separation  away  from  a  monolithic  supervisor  was  also  guided 
by  the  need  for  maintaining  optimum  integrity.  The  various  roles 
of  the  pitot  are  modelled  separately  with  appropriate  interlocks 
preventing  inappropriate  actions,  ibr  example,  a  change  of 
control  law  when  the  ACT  system  is  engaged. 


Figure  7  Pilot  Engage  and  System  Test  Processes 


2.6  Fault  tolerance  and  redundancy  management 

Within  the  function  and  operation  sections  of  the  unit 
descriptions  consideration  must  be  given  to  the  redundancy 
managment  and  fault  monitoring  issues  of  the  multiplex 
elements.  The  main  criterion  for  tolerance  is  that  the  system 
should  be  first  fail  operative,  and  the  identification  of  a  fault 
should  alert  the  pilot  to  return  control  to  the  safety  pilot  and 
conventional  inceptors,  by  a  controlled  disengagement  of  the 
ACT  System.  Faults  in  a  unit  are  detected  by  downstream 
comparison  of  its  outputs  with  those  of  its  siblings  (associated 
units  or  lanes  within  the  element  -  its  partners  within  the 
redundancy).  This  recognition  is  dealt  with  in  three  ways: 

(i)  The  consolidation  of  the  redundant  signals  must  not  be 
affected  by  one  signal  being  in  error.  There  are  two  type  of 
information  to  consider  here.  The  first  type  is  'analogue'  or 
continuous  type  of  data  where  the  median  select  is  used  for 
triplex  architectures,  the  second  type  is  discrete  data  where  a 
majority  vote  is  employed,  both  of  these  are  passive  fault 
masking  operations  used  to  collect  valid  data  for  subsequent 
processing. 
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(ii)  The  error  must  be  recognised  and  signalled  to  the  system  and 
the  pilot  via  the  appropriate  panel  lamp  -  this  is  the 
monitoring  aspect. 

(iii) Thcre  must  be  a  rcconfiguiation  triggered  by  the  signalling  of 
the  error  in  order  to  isolate  the  faulty  unit.  Th.t  isolation  is 
done  by  ignoring  all  of  the  outputs  of  the  faulty  unit. 

A  dual-duplex  arrangement  operates  in  a  different  manner, 
where  each  pair  of  units  carries  a  validity  signal  and  outputs  the 
validity  status  alongside  the  functional  The  downstream 
units  can  thei  mask  the  faulty  unit  by  a  tolerant  behaviour  or 
reconfiguration.  The  ACT  System  has  in  its  initial  form,  a  dual 
duplex  ADME,  originally  to  be  compatible  with  the  dual 
hydraulics  of  the  actuator,  and  the  single  fault  lolerana  arises 
from  the  disconnection  of  a  faulty  pair  of  units  from  the  drive  to 
the  actuator;  the  perfonnance  of  die  drive  being  such  that  it  can 
tolerate  .such  a  n^clion  of  input.  The  processing  elements, 
CLISE,  CLE  and  CLOSE,  are  triplex,  but  have  no  cross 
connections  at  their  mumal  interfaces  .(There  is  a  modicum  of 
sibling  monitoring  in  the  consolidation  of  discrete  data.) 
ConsquenUy  they  effectively  form  a  single  triplex  module.  The 
SE  and  the  CSE  are  essentidly  triplex  with  a  full  number  of 
cross  connections  to  the  CLISE. 

2.7  The  adequacy  of  the  Issue  3  Specification. 

The  ACT  System  elements  and  the  functions  they  performed 
were  conceived  and  assembled  from  the  combined  engineering 
experience  of  the  project  team.  This  included  first  hand 
experience  with  design  of  conventional  control  systems  and 
direct  exposure  to  the  helicopter  digital  flight  control  system 
programmes  in  foreign  Industry  and  Government  research 
laboratories.  The  FOFS  requirement  for  ACT  Lynx  combined 
with  the  need  forsignificant  flexibility  in  operation  created  new 
problems  however.  The  completeness  and  validity  of  the 
upgraded  Issue  3  ACT  Lynx  specification  had  to  be  questioned. 
Were  the  performance  figures  achievable  in  practice?  Would 
there  be  smooth  operation  through  the  PCP?  Would  the 
redundancy  management  logic  work?  In  many  projects  it  is 
apparent  that  answers  to  these  kind  of  questions  are  deferred 
until  deep  into  the  detached  design  phase,  oRen  when  the 
customer  is  no  longer  closely  involved.  RAE  needed  to  increase 
confidence  and  reduce  the  risk  associated  with  these  questions;  it 
was  decided  to  embark  on  the  development  of  a  fully  operational 
prototype  simulation.  An  incremenutl  approach  naturally 
complemented  the  ISD  methodology. 

3.  DEVELOPMENT  OF  AN  ADA  SIMULATION 

This  section  describes  the  approach  taken  The  organisation  of 
the  section  is  based  on  the  three  miuoi  parts  of  the  solution, 

ISD,  simulation  and  code  generation.  For  each  there  is  a 
description  of  the  approach  and  a  justification  for  choosing  it. 
Finally,  the  solution  is  assessed  against  tlie  initial  requirements 
for  the  project. 

3. 1  An  Overview  of  the  Approach 

The  approach,  in  brief,  was  to  use  the  Jackson  System 
Development  method  (ISD),  coupled  with  automatic  code 
generation  in  order  to  produce  a  simulation  of  the  .XCT  system. 
An  LBMS  CASE  tool,  Jackson  Workbench  (JWB)  was  used  to 
capture  die  specification  of  the  system,  and  subsequently  to 
generate  the  code.  The  simulation  was  delivered  in  six 
inerements,  with  consultation  between  RAE  and  LBMS 
following  each  increment. 

JSD  is  used  to  provide  a  behavioural  description,  derived  from 
the  textual  specification,  which  Is  expressed  in  enough  detail  to 
be  executable.  The  whole  description  is  expressed  as  a  network 
of  communicating  sequential  processes  connected  via  message 
queues,  and  with  read-onl<’  access  to  each  othefs  data.  A 
separate  description  is  made  of  the  hardware  configuration  on 
which  this  network  must  mn,  in  terms  of  hardware  units  and 
connections  between  them.  The  two  descriptions  are  then 
mapped  one  to  another  by  partitioning  the  processes  in  the 
network  onto  particular  hardware  units.  This  mapping  is  used 
as  the  basis  for  determining  the  fault  detection  and  recovery 
configuration.  Finally  code  generation  is  used  to  take  this 
complete  description  and  build  a  simulation  which,  besides 
simulating  the  system,  provides  a  range  of  facilities  such  as 


injecting  errois  into  the  simulated  hardware  and  producing 
diagnostic  information  for  off-line  analysis. 

The  adoption  of  incremental  delivery  must  be  viewed  as  a 
success.  It  was  inevitable  that  RAE  when  presented  with  the 
simulation  should  And  discrepancies  between  their  view  of  the 
system  and  its  behaviour,  either  through  misinteipretation  of  the 
specification  by  LBMS,  or  throu^  inconsistency  or  ambiguity 
in  the  specifiration.  Incremental  development  and  delivery 
allowed  these  discrepancies  to  be  identi‘'ed  corly  and,  if  desired, 
corrected. 

3.2  Jackson  System  Development. 

Jackson  System  Development  is  used  in  order  to  analyse  the 
existing  textual  specification  and  provide  a  formal  executable 
specification.  The  method  was  jointly  developed  by  Michael 
Jackson  and  John  Cameron  in  the  early  1980s  (references  7  and 
8).  Since  its  release  it  has  been  used  in  the  development  of  a 
number  of  significant  real  time  systems  including- 

(a)  The  control  software  for  a  torpedo. 

(b)  A  submarine  command  and  control  system. 

(c)  A  wind  tunnel  control  system. 

(d)  An  army  wide-area  network  command  and  control 
system. 

The  technical  method  consists  of  three  stages,  model,  network 
and  iniplementation.  These  stages  are  described  briefly  below 
illustrated  by  examples  taken  from  the  ACT  Lynx  project 

3.2. 1  Modelling.  A  JSD  model  is  constmeted  of  entities  and 
actions.  It  is  a  logical  description  about  a  "real  world”  with 
which  the  system  must  deal.  Actions  are  events  which  occur  in 
the  "real  world"  which  are  interesting  to  the  system  being  built. 
Entities  are  the  objects  in  the  "real  world”  which  perfomi.  or 
sometimes  suffer,  the  actions.  Figure  8  shows  a  typical  list  of 
actions.  Figure  9  describes  the  order  in  which  a  subset  of  those 
actions  must  happen  via  a  lime  ordering  diagram. 


Action  &  Os 

Summary 

ARnbutos 

arM 

hie  pilM  lequcsu  itui  ihc  lyMem  be 

AkMED 

llie  actuaior  poeiiions  ind  ihc 
control  law  demanda  are  in  hannony 

AK.M.DEFAt.'LT^ODE 

llie  inliiai  arminf  0/ a  defKilt 
control  mode 

lb  MdDE.fb.lVfE 

CA.NttL„SYSTEM 

.TEST 

A  requeai  to  cancel  the  aywem  i»i 

COTJw; 

ThU  U  the  elioal  to  mode  to  $0 
from  ARM  10  ARM.  AND  IN  CAP 

16'M6BE_Ib_TVrE 

Lt>Mt'Lblbi>  SYbltM 
lEST 

All  leaia  ol*  the  lyvtcm  tmliBve 
been  succeufuly  completed 

5V§lliM 

.TEST 

Indication  that  ine  current  icsi  ol  the 
lyttetn  teat  hu  been  McceMfully 
completed 

DIStNCACE 

llie  tyatem  has  been  disengaged 

This  may  happen  before 
engagement  (1)  by  the  pilot  pressing 
the  disengage  button  or  (2)  by  the 
system  tading  to  gel  into  the 

ARMED  or  ENCAGED  state. 

It  may  happen  whilst  ENGAGED 
on  rrcnpi  of  a  signal  from  an 
achiaior  relaying  the  fact  that  it  has 
become  diKOgaged 

'n6WN.t>!5TUWiANCr 

.REQUEST 

The  pilot  Wishes  to  be  oiTcred  the 
previous  valid  disturbance,  (hat  u 
the  fust  disturbance  with  a  lower 
index  number  (ID) 

This  u  equivalent  to  tlie  pilot 
presssing  the  DOWN  button 

biNOAOt 

Ihe  pik4  requests  (successfully) 
that  the  system  be  enpged 

fAlL.iEST_SrAOB 

Ihe  current  'automatic'  stage  of  the 
system  lev*  has  not  been 
successfully  com;^.cted 

TOTPTCiicratir 

A  new  value  refwescniing  the 
current  position  of  an  inceptor 
amves 

Figure  8  Typical  List  of  Actions 


Time  ordering  diagrams  are  tree  diagrams  which  use  JSP 
notation.  The  root  is  named  aRer  the  entity  performing  the 
actions;  the  leaves  (the  lowest  level  boxes  which  are  named 
rather  than  numbered)  contain  the  names  of  the  actions 
performed  by  this  entity.  The  internal  nodes  of  the  tree,  i.e. 
those  between  the  toot  and  the  leaves  describe  different  ways  of 
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Figure  9  Pilot  Engagement 


ordering  their  children  and  are  of  three  types;  sequence,  selection 
and  iteration,  identified  by  a  symbol  in  the  lop  right  comer  of  the 
box.  An  asterisk  (*)  represents  iteration,  that  is  one  or  more 
occurrences;  a  circle  (o)  represents  selection,  i.e  mutually 
exclusive  choice,  and  the  absence  of  a  symbol  represents 
sequence,  that  is  all  of  the  children  of  the  node  read  from  left  to 
right.  The  numbered  operations  attached  to  the  action  leaves 
indicate  how  the  slate  of  the  object  (or  entity)  is  changed  when  it 
receives  the  action. 

Figure  8  shows  a  list  of  actions,  that  is  events  of  interest  to  the 
ACT  Lynx  system.  Some  of  Ih^  actions  occur  in  the  lime 
ordering  dlagiam  for  PILOT.ENGAGEMENT  in  figure  9;  from 
it ,  one  can  see  that  the  standard  sequence  of  events  (under  the 
box  NORMAL  CYCLE)  consists  of  the  pilot  pressing  the  ARM 
button,  followed  by  the  system  ARMING  itself,  which  is 
followed  by  the  pilot  ENGAGING  the  system,  and  finally  the 
system  is  DISENGAGED.  Note  that  there  is  an  alternative  to  the 
NORMAL  CYCLE  (indicated  by  the  circle  in  the  lop  right 
comer):  this  is  called  EARLY  DISENGAGE  and  corresponds  to 
the  possibility  of  the  system  being  DISENGAGED  at  any  point. 
The  entire  ENGAGEMENT  CYCLE  can  happen  many  limes 
(indicated  by  the  asterisk  in  the  top  right  comer). 

In  a  completed  model,  the  total  set  of  tree  diagrams  describes  all 
of  the  time  orderings  of  the  actions  plus  the  changes  in  system 
state  which  they  cause. 

3.2.2  Network.In  this  stage  a  network  of  communicating 
sequential  processes  is  constiucled.  (Figure  10  provides  an 
example.)  The  three  elements  of  the  notation  are  processes 
(boxes),  data  streams  (circles)  and  suite  vector  inspections 
(diamonds).  The  meaning  and  use  of  these  symbols  is  described 
below. 

The  basis  for  the  network  is  the  set  of  entities  defined  during 
modelling;  the  suite  of  the  entity  is  recorded  in  the  local  data  ofa 
process,  and  the  actions  become  messages  passed  to  the  process 
via  an  input  data  stream.  Pilot  Engagement  (The  entity  d^ribed 
in  Figure  9)  appears  in  Figure  10  where  its  suue  is  inspected  by 
the  control  law  algorithm  process.  Processes  derived  from  the 
entities  in  the  model  are  called  model  processes.  During  the 
network  stage  new  processes  are  add^  to  take  messages  from 
the  system  boundary  and  feed  them  into  the  model  processes, 
and  to  use  data  stor^  in  the  model  processes  in  order  to  generate 
system  outputs. 

A  JSD  process  may  have  many  instances,  each  execuU'ng 
concunently  and  each  possessing  its  own  local  daui,  collectively 
known  as  the  state  vector  of  the  process.  The  control  flow  of  all 
instances  of  the  process  is  identical,  and  is  described  by  a  tree 
stmeture.  Processes  communicate  via  message  queues  (data 


streams),  or  by  read-only  access  to  each  others  state  vectors 
(State  vector  Inspections). 

The  example  in  Figure  10  shows  the  connections  to  the  control 
law  algorithm,  which  inspects  data  from  sensors  and  inceptors 
(e.g.  the  state  vector  connection  CL1SE_AMSE_DATA, 
providing  daUi  from  the  Air  Motion  Sensing  Element), 
computes  new  actuator  values  in  the  process 
CONTROL_LAW_ALGORn‘HM,  and  then  relays  them,  via  the 
data  stream  ACTUATOR_DEMANDS,  to  further  processing 
elements  and  eventually  to  the  control  surfaces. 


patatneters  cljsc_bcep_irim 


Each  process  is  described  in  deuiil  using  JSP  notation;  in  fact  the 
JSP  method  can  be  used  to  develop  the  process  descriptions. 
Figure  1 1  gives  as  an  example  the  process  responsible  for 
interacting  with  the  pilot  when  he  is  selecting  control  laws.  The 
process  executes  operations  which  store  suite  as  well  as  reading 
from  input  data  streams  (READ),  writing  to  output  data  streams 
(WRITE),  and  inspecting  other  processes  data  (GET_SV).  In 
this  way  the  process  is  available  to  gather  data  and  provide 
responses  via  its  connections. 

3.2.3  ImDlementatlon.The  network  which  results  from  the 
previous  step  is  detailed  enough  to  be  executed,  but  rarely 
match^  the  implementation  environment:  it  often  has  mote 
concurrency  thw  the  target  (each  process  instatKe  in  the 
specification  executes  concurrently  with  every  other),  and  data 
stored  in  the  processes  sometimes  has  to  be  separated  out  into 
files  and  databases. 

The  implementation  step  is  about  fitting  the  specification  to  the 
target  environment.  It  is 

discussed  in  greater  detail  in  the  simulation  section. 

3.2.3  Summary  The  main  aim  of  the  JSD  method  is  to  provide  a 
specification  which  can  be  usefully  viewed  from  both  above  and 
below.  The  modelling  stage  is  a.i  object  oriented  analysis  of  the 
r^  world  which  produces  a  description  which  users  can  readily 
grasp,  because  the  result  is  describe  in  terms  of  objects  familiar 
to  to  the  user.  It  also  provides  in  an  accessible  form  (tree 
diagrams)  important  detail  about  the  model  of  the  real  world. 

The  network  stage  uses  two  descriptions,  one,  data  flows, 
which  can  be  presented  to  the  user  to  indicate  the  architeemre  of 
the  system,  the  other,  tree  diagrams,  which  the  analyst  can  use 
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which  ensures  that  all  Tunctional  issues  have  been  aired.  In 
addition,  the  speciHcation  network  teaches  to  the  boundaty 
of  the  system  thus  providing  details  of  the  system  interface. 

(ii)  Fitness  for  Purpose 

(a)  Distribution/Concurrency.  A  completed  JSD  network  is 
highly  distnbuled,  which  maps  well  onto  this  type  of 
application,  where  the  processing  is  distributed  over  many 
processors. 

(b) Separalion  ofConcems.  The  specilication  phase  ends 
with  the  network  still  not  committed  to  a  particular  hardware 
conliguration.  Not  only  docs  this  provide  a  logical  view  of 
the  system  uncluttered  by  hardware  constraints,  but  it  also 
allows  considerable  flexibility  when  allocating  processing  to 
available  resources. 

(c)  Real  Time  Track  Record.  JSD  has  been,  and  is  still 
being,  used  on  a  number  of  large  real-time  projects,  with 
Ada  as  the  larger  language. 

(d)  Evolutionary  Delivery.  JSD  is  a  compositional  method 
sometimes  termed  ''middle-out”.  In  JSD  terms,  once  a 
model  has  been  built,  every  new  function  added  provides  a 
potential  deliverable,  working  system.  This  allows  the 
system  to  be  delivernl  in  a  tnily  incremental  fashion. 

3.3  Simulation. 

Having  prepared  the  JSD  design,  which  in  itself  has 
authenticated  the  textual  specification,  there  is  the  opporhinity  to 
progress  to  a  full  simulation  by  implementing  the  design  This  is 
a  definite  additional  step  and  it  is  worth  identifying  the  additional 
benefits  which  accrue; 

(i)  Dynamic  and  Sialic  Analysis.  The  essence  ofbullding  a 
reptesentative,  working  simulation  of  a  required  system  is 
that  it  provides  unequivocal  feedback  on  the  validity  and 
viability  of  the  specification.  This  feedback  is  provided  via 
analysis  of  various  forms. 

(ii)  Verification  of  Behaviour.The  most  obvious  form  of 
feedback  is  In  the  behaviour  of  the  system.  Even  good 
textual  specificaliotts  contain  a  great  deal  of  ambiguity,  and 
even  it  the  system  agrees  with  the  original  specification  it 
may  not  be  acceptable.  A  running  system  that  provides  the 
feed  back  required  to  verify  the  behaviour  as  described  in  the 
original  specification. 

(iii)  Estimation  of  Hardware  Requirements.Howcvergood  your 
estimating  technique,  the  more  representative  data  that  you 
can  provide  to  it  the  belter.  A  working  system,  even  though 
it  may  not  be  entirely  representative  of  the  final  system 
provides  an  excellent  b«is  for  estimation. 


(b)  The  CLE  Control  Law  Selector  Operations 
Figure  1 1 

to  express  the  design  of  a  particular  function.  The  resulting 
specifit^ion  can  be  view^  by  users  from  above  because  it  is  in 
terms  of  their  real  world  and,  simultaneously,  the  specification 
contains  enough  detail  for  the  implementers  below  to  perform 
their  tok.  It  is  this  general  property  that  made  JSD  particularly 
attr^tive  for  the  ACT  Lynx  specification,  although  the 
application  was  concerned  with  more  than  just  sofiware. 
However  when  a  simulation  of  the  specification  was  envisaged 
the  established  features  of  the  JSD  method  became  very  relevant 
In  particular 

(i)  Formality  and  completeness. 

(a)  M^elling.  The  semantics  of  the  modelling  notation  are 
lormal,  which  allows  a  formal  description  of  the  interaction 
betwwn  the  pilot  and  the  system,  in  temis  of  thepiiot  actions 
and  the  states  into  which  the  system  is  driven,  to  be 
prt^uced  fiom  as  a  result  of  the  modelling  stage  Figures  8 
and  9  provide  examples  from  the  project. 

(b)  Network.  The  network,  once  completed,  describes  the 
entire  functional  behaviour  of  the  system  to  a  level  of  detail 


(iv)  Cost  and  Flexibility  (compared  to  the  real  system)  The 
obvious  choice  for  an  implementation  of  the  specification  of 
the  system  is  to  build  the  system.  However  in  this  case  that 
would  have  been  prohibitively  expensive.  In  addition, 
because  of  the  experimental  nature  of  the  hardware 
configuration,  a  one  olf  solution  did  not  meet  requirements. 
The  obvious  choice  was  simulation. 

Given  a  detailed  description  of  the  behaviour  of  the  system  using 
the  first  two  steps  of  JSD,  the  final  step  is  to  implement  the 
system  by  fitting  the  specification  network  onto  the  hardware 
architKture.T^e  ACT  system  is  to  be  implemented  on  a  multiple 
node,  fault  tolerant  network  of  processors  with  the  requirement 
to  perform  fault  monitoring,  fault  prevention  and  fault  recovery 
to  provide  FOFS  system  with  respect  to  hardware  errors.  Both 
the  hardware  and  helicopter  are  simulated.  The  finished  system 
runs  on  a  single  IBM  PC,  or  compatible. 

tblijwarq^nffasttucture  BescriDtion.ln  order  to  describe 
the  hardware  configuration  and  the  associated  fault  tolerant 
infrastructure  a  new  definition  language  has  been  created. 
D^riptions  in  this  language  can  be  entered  using  JWB  and 
subsequently  stored,  in  the  same  fashion  as  the  JSD 
descriptions.  Figures  1 2(a)  -  (d)  provide  examples  of  the 
deKriptions  used;  Figures  12(a)  and  12(b)  describe  what  will 
be  hardware  units  in  the  final  architecture.  A  number  of  options 
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UNIT  IE 
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[•JSUMMARY 

■nils  unit  is  conneded  to  the 
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NO 
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CIINTRA-UNIT-CONNECTIONS 

UNIT-SID 


(a)  Unit  Description 


UNIT  CLE 
STD-INFO 
LONGNAME 
REFERENCE  aE 
[‘ICLASSIFICATION-SET 
[•JSUMMARY 

This  umt  houses  the  control 
law  algonthm  and  associated 
processing  It  is  the  middle  processor 
in  a  three  processor  'lane'. 
[olNARRATIVE 
NO 

MAIN-PART 

[oJTYPE 
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[olBASE-REDUNDANCY 
SIMPLEX 
REPLICATION  3 

[olUNIT-LVL-SYNCHRONISATION 
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FRAME-LAG 

[•JINTRA-UNIT-CONNECTIONS 

UNIT-SID 


CONNECTION  IE  aiSE 
STD-INFO 
LONGNAME 
REFERENCE  lEQ.IS 
[•[CLASSIFICATION-SET 
[•JSUMMARY 
[olNARRATIVE 
NO 

MAIN-PART 
SOURCE  IE 
DESTINATION  aiSE 
[opATA-TRANSMISSION 
BROADCAST 
[oJSPEC-INTERFACE 
NO 

[oJCONSOLIDATION 

YES 

HISTORY  LENGTH  3 
[oJSIBLING  ERROR  MONITORING 
YES 

HISTORY  LENGTH  3 


(b)  Element  Description 


(c)  Connection  Description  (d)  CLE  Implementation  Diagram 

Figure  12. 


are  provided,  including: 

(a)  The  type  of  unit,  analogue  or  digital  (the  CLE  is  one  of 
the  main  digital  units  in  the  system); 

(b)  How  many  units  (the  system  is  mainly  triplex  so  most  of 
the  units  have  a  replication  of  3); 

(c)  Whether  the  replicated  units  run  in  synchrony  or  not. 

Figure  1 2(c)  describes  a  connection  between  the  CLISE  and  the 
Inceptor  Element.  The  options  which  govern  connections  are 
largely  concerned  with  fault  tolerance  (described  below) 
including: 

(a)  Whether  consolidation  is  applied  to  the  data,  and  if  so 
over  how  many  frames  the  consolidation  is  performed; 

(b)  Wfielher  the  multiple  sources  of  the  data  are  compared 
for  consistency  (downstream  monitoring); 


(c)  Wlielher  the  siblings  of  the  current  unit  arc  tested  for 
agreement  (sibling  monitoring); 

Figure  1 2(d)  is  a  pictorial  representation  of  the  mapping  between 
the  specincalion  network,  and  a  unit  (in  this  case  the  CLE).  The 
rectangle  at  the  top  corresponds  to  a  task  type,  with  the  network 
processes  converted  via  a  standard  transformation  strategy  into  a 
procedure  calling  hierarchy;  processes  nearer  the  top  call  those 
connected  directly  beneath  them  Data  external  to  the  CLE  is 
shown  via  the  disk  symbols,  with  access  shown. 

3.3.2  Implementation  in  AdaThere  are  many  possible  mapping 
schemes  between  JSD  and  Ada;  References  16  and  17  describe 
two.  The  mappings  for  this  project  is  broadiy  on  that  described 
in  Reference  i 7.  This  mapping  relies  very  heaviiy  on  packages, 
the  aim  being  to  produce  a  set  of  Ada  packages  where  each 
corres^nd  only  to  one  specification  object  (e.g.  process  or  data 
streamL  This  enhances  the  traceability  from  the  JSD 
specification  to  the  Ada.  The  most  obvious  extensions  to  this 
mapping  scheme  for  ACT  applications  ate: 
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(a)  each  unit  type  ij  mapped  onto  a  task  type.  Figure  13 
shows  the  Ada  for  the  UNIT  described  in  Figure  12(b).  The 
replication  of  units  is  achieved  by  declaring  an  array  of  the 
task  type  for  the  unit  with  a  nix'tiplicity  equal  to  the 
REPLICATION  factor  specified  in  the  UMT  object,  which 
in  the  case  of  figure  12(a)  is  3. 

(b)  the  infrastiuctuie  which  provides  the  fault  tolerance  is 
described  using  a  number  of  generic  packages  which  are 
instantiated  ba^  on  the  information  in  the  connection 
object 

3.3.3  Implementation  of  Fault  Tolerance  Figures  f4(a)and 
14(b)  describe  the  connections  between  the  Inceptor  Element 
and  the  CLISE,  and  the  fault  tolerant  software  sited  in  the 
CLISE  to  handle  the  data  passing  between  the  two  units.  The 
fault  tolerant  strategy  was  based  on  that  described  in  Reference 
1 8.  The  connections  between  the  IE  and  the  CLISE  ate 
BROADCAST  as  indicated  in  Figure  12(c),  that  is  every  IE 
sends  to  every  CLISE.  Figure  1 2(c)  also  indicates  that  each  of 
consolidation,  downstream  monitoring  and  sibling  monitoring 
arc  enabled.  The  schematic  diagram  in  Figure  i4(b)  shows  the 
type  of  fault  processing  which  takes  place.  Voting  is  always 
present  where  there  are  many  sources  for  the  same  data.  The 
voted  value  is  obtained  by  cither  majority  vote,  or  median  select 
depending  on  the  type  of  data.  Downstream  monitoring  implies 
comparing  the  values  coming  from  each  of  the  data  sources  with 
the  voted  value.  If  any  of  the  sources  differs  for  more  than  a 
given  number  of  frames  (HISTORY-LENGTH  in  figure  12(c)), 
then  an  error  is  logged  and  the  voter  ignores  all  subsequent  input 
from  that  source.  Consolidation  is  performed  by  comparing  the 
historical  values  from  each  sibling,  gathered  over  previous 
frames.  Aconsolidaterwill  only  output  a  new  value  if  it 
perceives  that  all  of  its  siblings  agree  with  it.  Sibling  monitoring 
liiiplics  companng  the  voted  values  coming  from  the  siblings  of 
the  unit,  rather  from  upstream  sources.  Otherwise  the 
processing  is  identical,  with  an  error  being  logged  when  a 
discrepancy  occurs.  'Ihe  sibling  which  is  diagnosed  as  being  in 
error  is  then  ignored  by  the  consolidation  process. 


with  CLE  10  TYPE  PACKAGE. 

USB  aE.ID.TYPE  PACKAGE, 
with  SYSTEM, 

package  ae.TASK  TYPE.PACK  is 

tuncton  CURRENT  ID  return  aE  10  TYPE, 
task  type  aE  TASK  TYPE  is 

pra^na  PRIORITY  (SYSTEM  PRIORITY'FIRST); 
entiy  INITIAUSE(IO.  inae  10  TYPE), 
entry  ENSURE  INITIALISAfiON, 
entry  FRAME  START(FRAME  NUMBER  in  NATURAL), 
end  aE  TASK  TYPE; 
end  aE  TASK  TYPE  PACK. 


Figure  13  CLE  Package  Specification 


3.3.4  The  Choice  of  Ada  as  the  Imolementation  lanituaacThc 
selection  of  Ada  as  the  implementation  language  was  determined 
by  the  following  considerations: 

(i)  DoD  Language.  Ada  is  a  DoD  mandated  language,  and  is 
also  "highly  recommended”  by  the  British  MoD,  which  has 
provided  a  large,  guarantied  market  for  Ada  compilers 
ensuring  a  great  deal  of  investment  from  compiler  vendois. 
This  fact  coupled  with  the  extensive  validation  tests  required 
by  the  DoD  has  resulted  in  a  number  of  very  high  quality 
compilers. 

(ii)  Language  features.  As  has  been  discussed  above,  packages 
and  tasks  have  been  very  important  in  implementing  this 
system.  In  addition  the  comprehensive  d^  typing  provided 
through  Ada  has  enabled  a  more  precise  specificaticn  to  be 
constnicted  with  a  resulting  increase  in  quality. 

(iii)  Tool  Availability.  The  code  generation  tool  Adacode, 
described  below  was  already  available  in  prototype  form  to 
serve  as  a  basis  for  the  project,  and  as  its  name  suggests 
generated  Ada. 


INCEPTOR  ELEMENT  (IE) 


CONTROL  LAW  SUPPORT  ELEMENT  (CLISE) 
(a)  IE  to  CLISE  interconnection 


(b)  Schematic  Diagram  of  Fault  Processing 


Figure  14 


3.4  Code  Generation. 

A  significant  contribution  to  the  success  of  the  project  was  the 
use  of  code  generation.  Several  factors  encourage  its  use  in 
projects  of  this  nature  including: 

(i)  Productivity.  The  most  obvious  gain  is  productivity.  The 
statistics  concerning  the  number  of  lines  of  code  and  even 
number  of  functions  (counted  using  function  point  analysis 
FPA))  were  very  high.  The  figures  obtained  from  the 
second  delivered  increment  were  as  follows: 

(a)  Function  Points  per  man  day  2.34 

(b)  Source  Lines  of  Code  per  man  day  204 

This  project  could  not  have  been  completed  within  budget 
and  timescales  without  the  use  of  code  generation. 

(ii)  Ease  of  Instrumentation.  The  requirement  for  dynamic 
analysis  will  doubtless  change  as  the  simulation  is  used. 
Because  the  system  is  generated  using  code  generation,  the 
instrumentation  can  be  changed  merely  by  altering  the  form 
of  the  Ada  templates  and  regenerating. 

(ill)  Evolutionary  Delivery.  One  of  the  important  factors  that 
supports  evolutionary  delivery  is  for  user  feedback  at  the 
specification  level  to  be  converted  cfTiciently  and  accurately 
into  implementation  changes.  With  automatic  code 
generation  directly  from  the  jpecification  this  is  assured 
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(iv)  Living  Specification.  One  of  the  major  problems  of 
maintaining  systems,  especially  computer  systems,  is  that 
the  behaviour  of  the  tunning  system  diverges  very  quickly 
from  the  ori^nal  specification  of  system  behaviour  once 
maintenance  begins.  Code  generation  provides  the  ability  to 
maintain  a  living  specification”,  i.e.  one  where  changes  to 
the  specification  are  automatically  represented  in  the 
implemented  system. 

This  feature  is  especially  important  in  the  case  of  the  ACT 
system  because  we  may  wish  to  evaluate  many  hardware  and 
error  monitoring  combinations  and  even  new  functions  in  the 
course  of  the  planned  ACT  research. 

(v)  Re-Implementation.  Another  important  benefit  of  code 
generation  is  that,  without  changing  the  ISD  specification  of 
the  system,  a  completely  different  set  of  code  can  be 
generated,  for  example  to  fit  the  system  onto  real  hardware 
or  onto  transputers.  (This  can  sometimes  be  achieved 
merely  by  changing  the  code  generation  macros,  but  may 
require  new  implemenUUion  objects  if  the  Implementation  is 
significantly  different.)  Therefore  the  investment  In  a  system 
specification  is  not  compromised  when  when  evolving  the 
system  towards  greater  realism. 


Code  generation  is  provided  by  a  prototype  Ada  code  generation 
tool  built  by  LBMS  which  has  been  significantly  enhanced 
during  the  life  of  this  project.  Figure  15  illustrates  the  workings 
of  the  tool.  It  uikes  the  description  of  the  system,  specified  using 
the  Jackson  Work  Bench  (iWB)  CASE  product  and  generates 
the  complete  system  from  it.  Data  Extraction  is  done  using  built 
in  facilities  of  the  CASE  tool.  The  code  templates  arc  combined 
with  the  specific  parameters  extracted  from  JWB  by  a 
proprietary  tool  called  JSP-MACRO.  The  code  generation 
approach  provides  a  great  deal  of  flexibility  with  respect  to 
changes  in  the  implementation  of  the  system.  Many  simple 
changes  can  be  achieved  purely  by  amending  the  templates. 

Even  large  changes  may  only  require  changes  to  the  data 
extraction,  leaving  specification  of  the  system  unchanged.  As 
well  as  tools  to  build  the  whole  system,  there  are  others  which 
rebuild  the  system  regenerating  a  minimum  of  Ada  based  on 
changes  and  still  others  which  create  test  harnesses  for  any  sub 
network  of  the  specification,  providing  a  cost-effective  way  of 
ensuring  quality. 


Figure  15  Operation  of  Code  Generation  Tool 


3.5  Reejuirements  satisfaction. 

This  section  concludes  by  taking  the  three  major  features  of  the 
solution  in  turn,  and  for  each  determines  which  of  the  initial 
rerpiirements  have  been  addressed. 

(i) JSD: 

(a)  Resolves  Ambiguity  -  providing  feedback  which 
enhances  the  tpiality  of  the  original  specification. 

(b)  Formalises  Interfaces  -  so  that  prospective  contractors  for 
specific  devices  have  a  precise  specification. 

(ii)  Simuiation: 

(a)  Provides  Limited  Hands  On  Experience  -  allowing  pilots 
to  evaluate  some  aspects  of  the  user  interface. 

(b)  Allows  Investigations  of  Control  Mechanisms  -  to 
resolve  theoretical  is.<ues. 

(c)  Allows  Verificalion  of  the  Acceptability  of  an 
Asynchronous  Implementation  -  which  is  an  important  and 
contentious  issue. 

(d)  Allows  Investigation  of  the  Tolerance  for  Critical 
Functions. 

(e)  Allows  estimates  to  be  made  about  required  processor 
power  and  memory  usage  -  via  sialic  and  dynamic  analysis 
of  the  system. 

(0  Allows  verification  of  the  error  handling  mechanisms  -  in 
particular  reconfiguration  and  system  test. 

(ill)  Code  Generation; 

(a)  Allows  alternative  designs  to  be  verified  -  including 
significantly  different  hardware  architectures.  This 
specifically  includes  a  potential  switch  to  a  synchronous 
architecture. 

(b)  Allows  alterations  to  the  testing  mechanisms,  including 
monitoring,  to  be  entered  and  Implemented  rpiickly. 

4.  EXERCISING  OF  THE  SPECIFICATION 

With  any  complex  system  the  problem  is  always  going  to  be 
ensuring  that  the  specification  is  complete  in  that  it  toi^ly 
describe  the  system  behaviour  for  all  eventualities.  In  addition 
to  complete,  it  must  also  be  appropriate,  correct,  testable, 
unambiguous,  and  subslanliatrid  -  together  forming  the 
CACTUS  rules.  This  Is  virtually  Impossible  for  any 
specification  written  in  a  non-formal  language  such  as  English. 
The  JSO  design  created  from  the  English  specification  was  to  be 
used  to  test ,  in  particular,  the  requirements  for  completeness 
and  unambigulty,  and  to  clarify  tte  interpretation  of  the 
document.  The  stnicture  of  the  JSD  forces  the  simulation  of  the 
specification  to  be  complete  within  itselfand  therefore  any 
omissions  in  the  functional  specification  must  be  corrected.  Any 
other  inconsistencies  become  apparent  when  the  simulation  of 
the  system  is  used  in  a  representative  way.  An  example  of 
incompleteness  came  t  *  right  when  the  first  increment  of  the 
simulation  was  exercised.  On  disengage,  the  warning  light  on 
the  pilots  control  panel  was  to  be  illuminated.  However,  the 
specification  did  not  include  any  way  to  reset  (i.e.  extinguish  the 
warning  light  once  lit).  This  omission  Iras  now  been  corrected 
and,  although  the  example  may  appear  trivial,  an  important  point 
to  note  is  that  even  though  the  functional  specification  had  Imn 
read  by  several  people,  no-one  had  detected  the  absence  of  such 
a  requirement. 

Once  the  deficiencies  in  the  specification  are  resolved  at  the 
inaemental  level,  the  simulation  can  be  completed  and 
exercised.  It  is  in  the  exercising  of  the  simulation  that  more 
potential  problems  can  be  highlighted  and  solved.  The  first 
objeaive  of  exercising  of  the  s'^tem  must  be  to  check  out  the 
compliarKC  of  the  simulation  with  the  original  functional 
specification.  A  thorough  check  cf  the  simulation  is  needed  to 
ensure  that  all  the  functionality  required  in  a  panio  't..  increment 
is  present.  This  is  not  an  insignificant  task  and  cai^iul  thought 
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needs  to  be  given  as  to  how  the  compliance  is  to  be 
demonstrate.  This  task  is  slightly  ease  by  the  incremental 
approach  possible  with  JSD.  The  first  increment  will  be  fairly 
simple,  hence  the  correlation  between  the  functional  specification 
and  the  simulation  should  be  fairly  straightforward.  As  the 
increments  progress,  it  is  only  the  increase  functionality  and 
any  associate  performance  requirements  that  need  to  be 
checke.  So  not  only  is  the  design  done  incrementally,  the 
compliance  checking  is  done  in  a  similar  manner.  Each 
increment  demonstrates  some  aspects  of  the  pro|rased 
functionality  of  the  system  and  can  be  exercised  in  a 
representative  way.  There  may  not  be  same  interface  as  in  the 
cockpit,  but  the  basic  pilot /system  interaction  can  be  adequately 
simulated  using  a  keyboard.  This  ability  to  interact  with  the 
simulation  was  particularly  useful  and  resulted  in  some  changes 
to  what  can  be  referred  to  as  the  Pilot  Vehicle  Interface  (PVI). 
For  example,  the  proposed  system  state  lights  on  the  pilots 
control  panel  were  changed  because  it  was  felt  that  the  exact 
status  of  the  system  at  some  points  in  time  was  not  obvious. 

Prototyping  systems  in  order  to  optimise  the  PVI  is  of  course 
not  new  and  several  specific  prototyping  languages  have  been 
developed  to  perform  that  role.  In  addition,  however,  because 
the  design  includes  the  description  of  the  functionality  of  the 
system,  using  the  JSD  approach  offers  the  opportunity  for 
examining  the  ability  to  estimate  of  processor  and  memory 
requirements.  Instrumentation  of  the  simulation  means  that 
whilst  exercising  the  system  estimates  of  the  computational 
power  of  the  required  processors  can  be  obtained.  These  results 
can  be  fed  back  into  the  non-functional  parts  of  the  of  the 
original  specification  It  has  always  been  a  contentious  issue  in 
prototyping  as  to  whether  the  software  produced  in  this  phase  of 
the  development  cycle  should  be  used  in  the  final  version  of  the 
system.  The  argument  against  using  prototype  software  has 
always  been  that  during  its  life  there  will  have  been  frequent 
changes  and  patches  so  that,  at  the  end  of  the  prototyping  phase, 
the  software  is  very  unslniclured.  However,  because  the 
changes  to  the  prototype  software  under  JSD  are  always  done  a 
the  high  level  design  and  not  at  the  code  level,  the  code  always 
stays  well  stiuctured  and  suitable  for  use  In  the  final  delivered 
system. 

One  aspect  of  the  specification  writing  which  has  been 
particularly  difficult  to  quantify  is  the  specification  of  tolerances 
In  any  redundant  system,  where  the  compansons  are  made  for 
fault  checking  purposes,  tolerances  need  to  be  set  against  which 
the  system  can  check  itself.  If  the  tolerances  are  set  too  close 
then  the  system  will  signal  an  error  where  none  exists,  if  the 
tolerance  is  to  wide  then  the  system  may  not  detect  an  error 
where  one  does  exist  -  or  alternatively  may  not  react  sufliciently 
quickly  to  it.  In  complex  systems,  several  tolerances  need  to  be 
set  at  various  strategic  points  throughout  the  system.  Without 
putting  those  tolerances  into  a  representative  system  and  then 
testing  that  system  it  is  dilTicull  to  ascertain  what  level  they  need 
to  be  to  provide  the  right  level  of  protection  Ibe  simulation 
allows  the  tolerances  to  be  input  and  easily  changed  so  that  the 
effect  of  various  levels  and  comhinations  of  tolerances  can  be 
established.  The  simulation  not  only  allows  the  examination  of 
tolerance  levels  with  a  correctly  functioning  system,  but  also 
allows  a  representative  selection  of  faults  to  be  injected  to 
establish  the  behaviour  of  the  system. 

In  a  modular  system  such  as  the  one  being  developed  here  (see 
Figure  I),  it  is  vital  to  define  rigorously  the  interfaces  between 
the  various  elements  to  enable  changes  and  upgrades  to  be  easily 
made  to  the  sytem.  JSD  enables  each  module  to  be  treated 
separately  and  the  design  method  enforces  a  rigorous  approach 
to  the  specification  of  die  interfaces.  This  has  the  added 
advant^e  that  different  system  architectures  can  be  tried  for 
parts  of  the  system  and  still  retain  the  integrity  of  the  generated 
executable  code.  Thus  quadniplex  systems  can  be  substituted  for 
triplex,  dual  duplex  substituted  for  triplex  and  so  on.  The 
implication  of  such  changes  can  be  investigated  by  a  further 
exercising  of  the  system  This  ability  is  not  only  valuable  during 
the  initial  stages  of  the  development  cycle,  but  also  later  when 
actual  solutions  arc  being  proposed  to  meet  the  specification. 

The  simulation  can  be  modified  to  represent,  and  then  exercised 
to  ensure  compliance  of,  any  propos^  solution;  thus  reducing 
the  development  nsk 

In  summary,  the  ability  to  exercise  a  simulation  of  the  proposed 
system  confimis  that  the  specification  writers  ideas  and 


assumptions  are  actually  valid.  It  is  a  very  valuable  tool  which 
allows  a  rigorous  checking  of  the  completeness  and  consistency 
of  the  original  specification.  The  exercising  of  the  simulation 
ensures  the  adequacy  of  the  design  and  allows  initial  processor 
performance  estimates  to  be  made.  By  mnning  the  simulation  of 
the  proposed  system,  fault  tolerances  can  be  set  -  a  task  that  is 
virtually  impossible  to  do  purely  from  a  theoretical  point  of 
view.  Alternative  architectures  can  be  implemented,  and  due  to 
the  modular  nature  of  the  design  method,  these  alternatives  can 
replace  the  original  design  and  tested  for  compliance.  Thus  the 
tool  has  a  valuable  role  to  play  all  through  the  development 
cycle. 

5.  THE  WAY  FORWARD 

At  the  time  of  writing  the  ACT  Lynx  project  is  at  a  hiatus. 
Estimated  procurement  costs  for  the  system  and  its  certification 
arc  high  and  are  likely  to  require  a  multi-partner  team  to  be 
affordable.  Both  UK  and  international  options  are  being 
explored  but  no  clear  way  forward  curcnlly  presents  itself. 
Activities  in  support  of  the  project  arc  continuing  at  RAE 
including  the  study  of  performance  /  trade-off  issues  associated 
with  trials  in  flight  (safely)  critical  areas.  The  role  of  the  safety 
pilot  is  cmcial  to  this  work  and  ground-based  simulations  [  18] 
have  been  conducted  -  and  are  planned  -  to  address  critical 
functional  questions  such  as  optimum  location  of  disconnects, 
backdriving  frequencies,  mismatch  tolerances  for  failure 
managment,  and  PCP  ergonomics.  In  parallel  with  these  topics, 
the  requirements  specification  will  continue  to  be  developed. 

The  current  operation  form  is  essentially  complete  in  its 
functionality.  Future  tasks  include: 

(a)  Instrumentatton  of  the  simulation  to  evaluate  end-to-end 
and  internal  performance  and  behaviour. 

(b)  Production  of  a  comprehensive  user  guide  to  the 
simulation. 

(c)  Comprehensive  exercise  of  the  simulation  to  validate  the 
specification  across  the  operating  spectrum. 

(d)  Upgrading  the  requirements  specification  in  line  with  ihc 
results  of  (a)  -  (c) 

(e)  Upgrading  Ihc  requirements  specification  to  include  a 
second  level  of  JSD  analysis,  i.c.  network  and  process 
diagrams  together  with  text. 

(0  Implementation  of  the  Ada  smiulalion  in  real  time  with 
representative  pilots',  engineer's  and  software  development 
stations 

Many  of  these  tasks  can  be  embarked  upon  concurrently  and  are 
not  specific  to  the  implementation  in  the  final  sj'stcm.  The 
results  from  these  activities  have  generic  value  and  can  be  used 
to  guide  and  support  similar  projects  for  example  Thccurrcnl 
Ada  simulation  has  been  developed  in  seven  increments  and  the 
approach  has  demonstrated  the  uillity  of  this  approach.  The 
simulation  has  'grown'  in  a  controlled  manner  with  each 
increment  offering  more  functionality  for  review  and  revision  if 
necessary.  The  approach  has  had  the  added  advantage  of 
enabling  the  software  engineers  to  develop  their  understanding 
of  the  application  incrementally.  A  top-down  approach  to  the 
design  would  have  required  considerably  greater  inveslnieiil  m 
'application  learning’  before  any  creative  work  could  have  been 
started.  It  is  recognised  that  there  are  contentious  issues  in 
system  development  and  that  there  are  no  right  or  wrong 
approaches.  JSD  has  exposed  functional  anomalies  and  forced 
hidden  issues  into  the  open  through  its  emphasis  on  design, 
however.  The  behaviour  of  the  ACT  Lynx  system,  as  currently 
configured,  is  now  well  understood  -  the  (light  cntical  nature  of 
the  application  makes  this  an  attractive  position  to  be  in. 

6.  CONCLUDING  REMARKS 

The  handling  qualites  opportunities  offered  by  active  control 
technology  for  helicopters  require  considerable  research  effort 
using  both  ground  and  in-flight  simulation  before  the  final 
potential  is  realised  Much  work  has  already  been  done  but  the 
peculiar  problem  areas,  such  as  carefree  handling,  of  high 
performance  levels  have  yet  to  be  explored  in-flight.  The  safety- 
cntical  nature  of  such  flight  research  demands  that  a  fail-operatc 
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design  concept  be  employed  covering  both  system  hardware  and 
software.  In  the  UK,  the  Royal  Aerospace  Establishment  has 
pioposW  the  procurement  of  an  experimental  ACT  system  for  its 
reseaich  Lynx.  This  paper  o.  bribes  the  development  of  the 
requirement  specification  for  the  aiibome  system  including  crew 
station,  sensors,  processing  elements,  actuation  etc.  In  its 
current  foim  the  requirement  is  a  textual  and  diagramatic 
description  of  the  system  behaviour  covering  functionality, 
operation,  performance,  testing  and  interface  requirements  The 
specification  is  supported  by  design  using  the  JSD 
methodology.  An  outcome  of  the  design  work  is  a  prototype 
Ada  simulation  of  the  system.  Examples  of  the  JSD  modelling 
and  the  mapping  into  Ada  have  been  described.  Initial  results 
from  exercising  the  simulation  have  been  presented.  Although 
the  overall  ACT  Lynx  pnyect  is  on  hold  until  an  affordable 
package  is  defined,  the  requirement  specification  continues  to  be 
evolve,  with  an  upgrading  scheduled  to  follow  from  a 
comprehensive  instrumentation  and  exercise  of  the  simulation. 

A  real  time  implementation  is  planned  which  could  form  the  core 
element  of  a  ground  system  to  support  software  development. 
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SUMMARY 

UK  MOD(PE)  identified  Ada'  as  the  single 
preferred  high  level  language  for  the 
implementation  of  defence  real-time 
operational  systems  from  1  July  1987. 

This  meant  that  projects  selecting  an 
implementation  language  after  that  time 
must  select  Ada,  unless  there  are  sound 
and  documented  reasons  for  using  an 
alternative. 

UK  (MOD)PE  therefore  decided  to  invite 
proposals  for  the  High  Order  Language 
Demonstrator  (HOLD)  to  examine  the 
applicability  of  Ada  to  an  aero  gas 
turbine  FADEC,  and  awarded  the  contract  to 
Lucas  Aerospace  Ltd,  Birmingham.  This 
paper  describes  the  work  carried  out  to 
date  by  Lucas  Aerospace  on  this  contract. 

1.  INTRODUCTION 

UK  HOD(PE)  identified  Ada'  as  the  single 
preferred  high  level  language  for  the 
implementation  of  defence  real-time 
operational  systems  from  1  July  1987. 

This  meant  that  projects  selecting  an 
implementation  language  after  that  time 
must  select  Ada,  unless  there  are  sound 
and  documented  reasons  for  using  an 
alternative. 

The  major  potential  benefit  of  the 
application  of  Ada  to  military  systems  is 
the  reduction  of  Life  Cycle  Costs  (LCCs). 
In  addition  Ada  is  a  truly  international 
standard  and  as  a  result  very  wide 
support,  in  terms  of  Programme  Support 
Environments  (PSEs)  and  industry  expertise 
can  be  expected.  Ada  also  provides 
facilities  for  structured  design  which 
holds  the  prospect  for  a  modular  approach 
with  verifiable  and  re-usable  software 
components. 

UK  MOD (PE) 's  concern  was  that  Ada  was  not 
yet  ready  for  incoiporation  into  full 
development  of  high  integrity  software 
based  systems,  such  as  flight  safety 
'critical'  Full  Authority  Digital  Engine 
Control  Systems  (FADECs). 

A  FADEC  is  a  real-time  control  system. 

The  control  requires  a  fast  execution 
time,  typically  in  the  order  of  20m8,  and 
all  of  the  functions  must  be  computed 
within  this  time  frame.  The  main 
functional  activities  are: 
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i)  Input  handling,  including 
sampling,  validation, 
averaging/filtering  and  scaling. 

ii)  Control  law  computation. 

iii)  Output  handling,  possibly 
including  status  and  fault  cods 
data. 

iv)  Fault  monitoring  and  detection, 
state  input  checks  and  Built  In 
Test  (BIT). 

v)  Fault  handling,  take  action  to 
implement  fault  procedures,  for 
example  change  control  lane  or  set 
the  system  to  a  safe  state. 

There  are  two  main  areas  of  concern: - 

Firstly  the  lack  of  visibility  of  the 
object  cods  and  its  characteristics. 

This  is  due  to  the  way  in  which  high  order 
language  (HOL)  sourced  object  code  is 
generated.  Software  is  written  in  the 
HOL,  and  then  converted  by  an  automated 
process,  compiled,  into  the  object  code 
that  will  be  loaded  into  and  used  by  the 
target  system.  Whilst  Ada  lays  down 
stringent  requirements  for  the  design  of 
compilers,  and  the  compilers  have  to  be 
formally  validated,  there  remains  a  doubt 
about  their  integrity,  and  certainty  of 
the  object  code  produced  actually 
representing  that  required  by  the  source, 
and  therefore  their  suitability  for  this 
application. 

Secondly  the  Size  of  code. 

The  use  of  the  full  Ada  language  with  many 
compilers  was  understood  to  be  inefficient 
in  the  production  of  object  code,  compared 
to  the  specialised  lower-level  languages 
being  used  for  aero-engine  control.  This 
would  result  in  many  times  more  computer 
memory  space  and  processing  power  being 
used  for  a  given  function,  and  would  be  a 
serious  limitation  to  the  use  of  Ada  for 
aero-engine  control.  However, 
restrictions  on  the  features  used,  and 
careful  optimisation  of  the  source  code 
might  greatly  alleviate  the  problem.  It 
was  expected  that  there  would  be  a  speed 
and  power  penalty  arising  from  the  use  of 
Ada,  but  it  was  considered  possible  that 
the  penalties  could  be  reduced  to  an 
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acceptable  level. 

UK(MOD)PE  therefore  decided  to  invite 
proposals  for  the  High  Order  Language 
Demonstrator  (HOLD)  to  examine  the 
applicability  of  Ada  to  an  aero  gas 
turbine  FADED,  and  awarded  the  contract  to 
Lucas  Aerospace  Ltd,  Birmingham.  This 
paper  describes  the  voik  carried  out  to 
date  by  Lucas  Aerospace  on  this  contract. 

2.  PURPOSE  AND  SCOPE 

The  purpose  of  the  HOLD  programme  is  to 
examine  the  applicability  of  Ada  to  a 
military  aero  gas  turbine  FADEC.  However, 
it  is  clear  that  much  more  can  be 
undertaken  whilst  pursuing  the  top  level 
objective.  To  ensure  that  the  programme 
is  as  "real”  as  possible  the  contractor 
has  been  required  to  base  the  programme  on 
an  existing  in-service  UK  military  FADEC. 

The  programme  therefore  covers s- 

i)  The  identification  of  those 
features  of  the  Ada  language  which 
conflict  with  the  requirements  for 
a  flight  safety  "critical”  aero¬ 
engine  control  system. 

ii)  The  utilisation  and  critical 
assessment  of  design  and 
development  methods  that  will 
provide  the  best  possible 
application  of  the  language  to 
this  type  of  system,  to  meet  both 
performance  and  integrity 
requirements. 

iii)  Re-programming  of  an  existing 
flight  certified  Engine  Electronic 
Control  (EEC)  in  Ada. 

iv)  Tha  assessment  of  the  efficiency 
of  the  executable  code,  and  the 
resulting  system  performance  and 
integrity,  using  the  existing 
flight  certified  EEC  as  a 
benchmark. 

Within  these  major  activities  the  HOLD 
programme  will  generate  much  valuable 
information  on  topics  such  as:- 

i)  Considerations  leading  to  the 
selection  of  the  compiler. 

ii)  Considerations  leading  to  the 
selection  of  the  support 
environment. 

iii)  Development  of  the  Ada  solution. 

iv)  Simulator  rig  testing  utilising  a 
reprogrammed  EEC. 

V)  Assessment  studies  to  identify  the 

benefits  and  penalties  of 
the  use  of  Ada. 

vi)  Selection  of  processor/computing 
power  to  implement  an  Ada 
solution. 


3.  REQUIREMENTS  OF  A  SAFETY  CRITICAL 
ENMNE  CONTROL  SYSTEM 

This  section  of  the  paper  attempts  to 
describe  the  features  and  life  cycle  of  an 
Aircraft  Engine  Control  System  which  may 
set  it  apart  from  other  avionic  embedded 
software  systems.  The  .nain  purpose  is  to 
highlight  the  main  differences  so  that 
some  of  tha  decisions  described  later  in 
tha  paper  can  be  better  understood. 

FADEC  system  software  is  generally  set  at 
the  critically  level  of  "Level  1"  software 
as  defined  by  RTCA/DO-178A.  The  "Radio 
Technical  Commission  for  Aeronautics,  DO- 
178A  Software  Considerations  in  Airborne 
Systems  and  Equipment  Certification" 
defines  Level  1  software  ass- 

Functiona  for  which  the  occurrence  of 
any  failure  condition  or  design  error 
would  prevent  the  continued  safe  flight 
and  landing  of  the  aircraft. 

Although  RTCA/DO-178A  is  a  civil 
certification  standard  recognised  by  both 
che  United  States  of  America  and  European 
certification  authorities,  it  is  the 
standard  which  was  adopted  for  the  flight 
certified  engine  control  system  being  used 
in  HOLD.  Consequently,  it  was  also 
adopted  for  the  HOLD  programme  so  that 
direct  comparisons  between  the  flight 
certified  engine  control  and  HOLD  could 
legitimately  be  made. 

It  is  worth  pointing  out  at  this  stage 
that  software,  used  for  engine  control, 
requires  a  computer  system  plus  the 
associated  input  and  output  conditioning 
for  it  to  operate  and  communicate  with  the 
outside  world.  The  design  of  this  system 
is  of  paramount  importance,  as  the  split 
of  functions  between  hardware  and 
software,  with  the  safety  featurer  embeded 
in  both,  provides  the  safety  critical 
system.  Software  running  in  isolation 
does  not  constitute  the  total  safety 
critical  system,  and  consequently  cannot 
be  considered  in  isolation. 

3.1  Description  of  a  FADEC 

3.1.1  FADEC  Functionality 

A  FADEC  comprises  all  the  sensors, 
actuators  and  computing  elements  that 
realise  engine  management.  The  (EEC)  is  a 
major  component  of  the  FADEC.  It  is 
beneficial  to  later  sections  of  this  paper 
to  segregate  the  'essential'  FADEC 
functions  from  those  functions  arising  as 
a  result  of  'how'  the  system  is 
implemented. 

3.1.2  Essential  Functions 

The  primary  purpose  of  the  FADEC  is  to 
control  a  gas  turbine  installed  on  an 
aircraft  throughout  the  flight  envelope. 
Thrust  demands  from  the  cockpit  and  flight 
management  computer  are  input  to  the  EEC. 
The  EEC  utilises  a  set  of  control  laws  and 
schedules  primarily  based  upon  engine  and 
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airfreune  measurements  of  pressures, 
temperatures  and  speeds  to  control  the 
prime  Interfaces  to  the  engine,  including 
fuel  metering,  variable  guide  vanes, 
engine  igniters,  engine  bleed  valves  and 
thrust  reversers. 

3.1.3  Additional  Functions 

The  FADEC  design  is  required  to  meet 
stringent  integrity  and  reliability 
requirements.  The  architecture  of  the 
FADEC  and  of  the  EEC  is  designed  to 
maximise  fault  accommodation.  The 
additional  functionality  required  of  the 
EEC  is: 

i)  To  condition,  calibrate,  validate 
and  select  input  signals  (critical 
inputs  are  normally  duplicated). 

ii)  Validate  correct  operation  of  and 
select  output  drives. 

ill)  Dormant  fault  detection. 

iv)  Redundancy  management. 

V)  Store  all  fault  data  for 

subsequent  retrieval  so  that  the 
status  of  the  FADEC  can  be 
established. 

vi)  Provide  test  features  to  aid  .nit 
development. 

3.2  Development  Life  Cycle 

One  of  the  major  differences  botween  an 
engine  control  system  and  other  avionic 
systems  is  the  software  life  cycle.  It  is 
not  unusual  for  a  development  life  cycle 
to  span  10  years  or  more  and  during  this 
time,t.>a  software  process  must  be 
sufficiently  flexible  to  accommodate 
numerous  changes.  Some  of  these  changes 
will  be  required  to  be  carried  out  in 
short  time  scales,  possibly  less  than  24 
hours  during  particular  stages  of  the 
development  life  cycle  such  as  engine  test 
cell  operation.  The  EEC  life  cycle  began 
in  1979  and  is  still  a  live  project  with 
software  modifications  being  planned  for 
this  year.  A  typical  project  for  civil 
application  can  last  as  long  as  5  years 
with  modifications  to  the  software  talcing 
place  after  entry  into  passenger  service. 

The  life  cycle  normally  begins  with 
software  requirements  that  are  incomplete. 
This  is  totally  understandable  as  the  life 
cycle  begins  while  the  engine  itself  is 
under  development.  The  engine,  in  return, 
requires  a  basic  control  system  to  operate 
it  so  that  the  engine  can  he  run  and  the 
development  process  continue. 

So  we  have  a  situation  where  both  the 
engine  and  its  associated  control  system 
are  under  development  and  continuous 
modification.  Thus  the  software  teams  do 
not  have  the  luxury  of  frozen,  complete 
and  unambiguous  requirements  until  quite 
late  in  the  project  life  cycle. 


The  majority  of  the  development  changes 
are  implemented  in  the  software  system  due 
to  the  fact  that  it  is  easier,  but  not 
necessarily  cheaper,  than  modifying  the 
hardware  system.  Therefore  the  software 
environment  employed  must  be  flexible  but 
must  provide  a  top  quality  product  without 
reliance  upon  formal  verification,  as  this 
task  is  impractical  during  the  engine 
development  process. 


3.3  Real  Time  Control  System 

The  term  "real  time"  means  many  things  to 
many  people,  from  data  entry  systems, 
supermarket  checkout  systems,  banking 
systems  to  control  systems  to  name  but  a 
few.  The  consequence  of  failure  to  carry 
out  a  certain  task  in  a  certain  time  for  a 
real-time  engine  control  is  an  error  with 
a  significant  consequence,  not  merely  an 
inconvenience.  Whan  this  situation  ariass 
it  must  be  dealt  with  in  a  correct  and 
safe  manner,  not  ignored.  This  feature  of 
engine  control  systems  has  a  profound 
effect  on  the  hardware  and  software 
systems  which  must  react  quickly  and 
safely  to  a  timing  error.  The 
requirements  for  the  engine  control  system 
must  contain  the  specific  time 
requirements  and  any  system  used  to 
provide  and  analyse  these  requirements 
must  have  the  ability  to  taka  time  into 
account.' 

3.4  Satt^wftta  VtEifimign 

The  verification  of  software  is  a  very 
important,  if  not  the  most  important, 
stage  of  a  software  life  cycle.  The 
outco&te  of  the  verification  stage  is  to 
show  that  the  software  meats  the 
req;iirements  and  only  meets  the 
requirements.  There  are  many  facets  of 
verification  including  functional  testing, 
structural  testing,  coda  review,  static 
testing  etc.  To  be  able  to  meet  the 
safety  levels  required  for  safety  critical 
software  the  testing  methodology  employed 
must  be  against  the  target  code  resident 
in  its  target  environment.  If  testing  is 
carried  out  against  source  code, 
emulators,  simulations  etc  than  this  will 
only  be  acceptable  if  the  following 
conditions  applyi- 

i)  The  source  code  to  target  cods 
process  has  itself  been  verified 
or  is  completely  analysed. 

ii)  The  tools  used  in  the  process  are 
themselves  verified  to  the  same 
level  as  the  software  criticality 
level. 


3.5  LUCOL* 

The  EEC  currently  in  production  was 
programmed  using  the  Lucas  Aerospace  LUCOL 
Progrcunmiug  system. 

The  basis  of  the  system  is  a  high  level 
application  oriented  language  consisting 
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of  a  series  of  LUCOL  Modules  representing 
commonly  used  analogue  control  system 
blocks  together  with  sequential  logic 
operations,  input,  output  and  safety 
routines.  The  control  engineer  solves  his 
problem  by  specifying  an  appropriately 
ordered  network  of  LUCOL  Modules.  These 
LUCOL  Modules  are  drawn  from  a  library  of 
rigorously  tested  microprocessor  targeted 
assembler  language  programs. 

Each  LUCOL  Module  has  a  mnemonic  identifer 
and  a  standard  functional  diagram  assigned 
to  it.  The  control  engineer  draws  his 
3ys..em  block  diagram  using  the  LUCOL 
Elements  -  this  block  diagram  then  forms  a 
pictorial  representation  of  the  software. 

The  basic  control  source  program  is 
generated  simply  by  producing  a  calling 
sequence  listing  the  LUCOL  Modules,  in 
mnemonic  form,  and  their  associated 
parameters.  These  parameters  specify: - 

i)  The  data  flow  between  LUCOL 
Modules  (analogous  to  the  signal 
flow  on  a  conventional  block 
diagram) . 

ii)  The  direct  parameters  such  as 
gains,  time  constants  etc. 

A  feature  of  LUCOL  is  that  a  LUCOL  Module 
may  use  the  output  of  the  previous  LUCOL 
Module  as  an  input  automatically.  This 
method  of  transference,  termed  "signal 
flow"  la  employed  by  most  LUCOL  kudules 
and  results  in  an  improvement  in  the 
efficiency  and  clarity  of  the  resultant 
control  program.  However,  in  a  few  cases, 
explicit  flow  is  used,  the  input  or  output 
being  defined  in  the  calling  sequence. 
Typically  this  method  is  used  in  such 
cases  as  hardware  interfacing  LUCOL 
Modules  where  several  parallel  operations 
are  likely.  This  again  is  to  optimise 
overall  efficiency. 

4.  HOLD  METHODOLOGY 

The  approach  adopted  for  the  development 
of  MOLD  was  to  reprogram  one  lane  of  an 
existing  FADEC  unit.  The  unit  chosen  was  a 
dual  lane  EEC  i.e.  it  had  two  identical 
independent  lanes  of  control.  Each  lane  of 
control  was  for  dry  engine  control  only, 
there  being  a  third  common  lane  of  control 
for  reheat.  The  advantage  of  choosing  such 
a  unit  was  that  we  could  replace  one  lane 
with  the  code  developed  for  HOLD  whilst 
retaining  the  original  software  of  the 
other  lane.  This  meant  that  during  testing 
of  the  unit  we  could  freely  change  lanes 
between  the  two  different  versions  of  the 
software  to  examine  performance. 

The  starting  point  for  the  software 
development  was  the  software  requirements 
that  had  been  used  to  develop  the  original 
software.  We  could  have  started  further 
back  along  the  development  path  at  the 
system  requirements  level  but  we  felt  that 
this  approach  would  lead  to  different 
design  implementations,  Chat  would  throw 
into  doubt  the  result  of  any  comparisons 


made  between  the  two  systems.  Likewise  we 
could  have  started  further  down  the 
development  path  using  the  design  of  the 
original  software  as  a  template  for  the 
Ada  software.  This  approach  was  also 
rejected.  Although  it  would  have  given  a 
very  good  basis  for  a  comparison  of  the 
physical  effects  of  the  two  systems,  it 
did  not  render  sufficient  flexibility  in 
the  design  process  to  explore  all  of  the 
inherent  structured  design  features  of 
Ada.  So  the  middle  road  of  choosing  the 
software  requirements  was  chosen  as  the 
optimum  starting  point,  bearing  in  mind 
that  we  would  have  to  keep  a  close  eye  on 
the  design  approach  to  ensure  that  the 
resultant  Ada  software  was  consistent 
functionally  with  the  baseline  software 
implementation,  and  thus  did  not 
invalidate  any  results  of  the  comparison. 

Once  this  starting  point  was  chosen,  the 
next  stage  was  to  decide  on  the 
implementation  approach  to  be  adopted  for 
the  specification  and  design  of  the  Ada 
software.  As  part  of  the  HOLD  programme  we 
wished  to  investigate  the  impact  that 
Formal  Methods  would  have  on  engine 
control  systems  and  to  see  where  such 
methodologies  would  yield  benefits  in 
terms  of  improved  software  production  and 
integrity. 

We  considered  implementing  the  whole  of 
the  software  requirements  using  a  Formal 
Method  but  decided  that  this  approach  was 
too  great  a  risk  to  the  programme.  The 
time  required  to  perform  a  full  Formal 
Methods  implementation  was  an  unknown  as 
was  the  effect  that  it  would  have  on  the 
subsequent  production  of  Ada  software.  As 
the  other  main  aim  of  the  programme  was  to 
investigate  the  suitability  of  Ada  in  an 
engine  control  environment  we  did  not  wish 
to  risk  an  approach  that  rxv  fail  at  the 
first  hurdle. 

There  was  also  the  unknown  regarding  how 
well  we  could  implement,  using  Formal 
Methods,  the  present  software  requirements 
due  to  their  structure  and  layout.  He  had 
to  be  sure  that  any  new  representation  was 
consistent  with  the  present  software 
requirements  and  included  the  same 
functionality. 

The  next  step  was  thus  the  selection  of 
the  approach  to  be  taken  to  represent  the 
software  requirements. 


4 . 1  Requirements  Capture 

We  decided  that  the  most  advantageous  way 
to  proceed  was  to  use  some  form  of 
computer  aided  software  engineering  (CASE) 
tool  to  capture  the  existing  software 
requirements.  This  exercise  could  also  be 
used  to  ensure  that  all  the  software 
requirements  were  captured  in  such  a  way 
that  the  subsequent  design  and 
implementation  of  the  Ada  solution  mirrors 
the  existing  software.  This  will  thus 
provide  reliable  comparisons  between  the 
two  systems.  There  are  many  methodologies 
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available  that  come  under  the  umbrella  of 
requirements  capture  or  analysis  and 
design  methods,  such  as  CORE,  MASCOT, 
SSAOM,  OOD,  Jackson  etc,  but  we  decided  to 
use  Yourdon'.  This  choice  was  based  mainly 
on  two  factors.  Firstly  our  knowledge  and 
experience  with  Yourdon  over  several  years 
and  secondly  the  availability  of  In-house 
tool  support  for  this  methodology.  We  had 
available  in-house  the  CASE  tool  Teamwork^ 
which  implements  a  Yourdon  baaed  system 
analysis  methodology  and  also  has  support 
for  structured  design. 

4.1.1  System  Analysis 

The  first  task  in  the  requirements  capture 
was  the  analysis  of  the  system.  This  is 
achieved  in  the  Yourdon  meti.odology  by 
creating  the  top  level  context  diagram. 
This  dsflnes  the  inputs  and  outputs  of  a 
system  and  thus  places  bounds  on  the 
extent  of  the  system.  This  top  level 
diagram  was  defined  by  searching  through 
the  software  requirements  for  Inputs  and 
outputs.  This  task  was  aided  by  the  fact 
that  the  hardware  devices  of  the  EEC  were 
fixed  and  thus  could  be  tied  to  Individual 
software  Input  and  output  functions.  To 
simplify  the  diagram  the  various  Inputs 
and  outputs  were  than  collected  together 
Into  logically  functional  blocks,  e.g. 
collection  of  all  angina  Input  data, 
speeds,  temperatures,  pressures  etc.  Into 
one  functional  block.  The  aim  was  to 
generate  functional  blocks  that  could  be 
identified  with  individual  system 
components,  e.g.  engine  data,  cockpit 
signals,  airframe  signals,  fuel  valve 
etc. . 

The  resulting  ro.itext  diagram  Is  shown  In 
figure  4.1. 

4.1.2  system  breakdown 

The  next  phase  of  the  requirements  capture 
process  was  to  breakdown  the  context 
diagram,  through  several  steps.  Into 
smaller,  and  logically  Independent, 
functional  tasks.  The  first  stage  of  this 
process  was  straightforward.  As  the  EEC 
performs  two  different  functions,  dry 
engine  control  and  reheat  control,  the 
first  level  of  partition  was  to  split  the 
context  diagram  along  this  functional 
boundary.  Than  as  the  dry  engine  control 
consists  of  a  dual  lane  system  the  next 
level  of  partition  was  to  split  the  dry 
engine  control  function  Into  the  functions 
of  the  two  lanes,  termed  lane  A  and  lane 
B.  As  the  lanes  are  functionally  Identical 
we  then  proceeded  by  continuing  the 
partition  for  just  one  of  the  lanes. 

The  breakdown  is  performed  under  the 
Yourdon  methodology  by  splitting  an 
overall  function  Into  smaller  and  smaller 
component  parts  or  processes  as  they  are 
termed.  This  hierarchy  consists  of  a  set 
of  what  are  termed  dataflow  dlagreuns.  Each 
dataflow  diagram  consists  of  a  set  of 
process  "bubbles",  a  set  of  Input  and 


output  flows  and  a  set  of  Inter-process 
flows.  Each  process  "bubble"  can  be  split 
Into  component  processes  thus  forming  a 
new  dataflow  diagram.  At  each  stage  of  the 
decomposition  the  data  flowing  into  and 
out  of  a  process  must  be  maintained.  To 
perform  this  task  data  composites  are  used 
to  group  together  dataflow  signals.  A 
dataflow  composite  Is  simply  a  collection 
of  dataflow  items,  which  may  be  either 
elemental  dataflows  or  other  dataflow 
composites,  that  are  grouped  together 
under  a  single  name.  Thus  at  one  level  of 
the  decomposition  a  process  "bubble"  as  It 
Is  termed  will  have  several  dataflow  Items 
flowing  into  and  out  of  it.  When  this 
process  "bubble"  is  broken  down  into 
several  component  procsns  "bubbles"  the 
composite  dataflows  can  also  be  split  and 
each  element  associated  with  it's 
component  process.  In  this  way  diagrams  at 
the  top  of  the  hierarchy  are  not 
complicated  by  a  mass  of  dataflow  but  by 
simple  composite  dataflows.  Figure  4.2 
shows  the  breakdown  of  the  tasks  for  lane 
A. 

For  HOLD  this  process  of  gradually 
splitting  the  overall  task  Into  smaller 
and  smaller  items  was  terminated  whan 
further  partitioning  yielded  no  benefits. 
The  decision  as  to  where  to  stop  the 
process  was  to  a  large  extent  arbitrary. 
The  main  goal  was  to  reach  a  point  that 
did  not  over  or  under  partition  a 
function.  If  the  level  Is  taken  too  low 
then  Individual  functions  could  be 
fragmented  and  not  easily  assimilated.  If 
the  level  Is  too  high  then  functions  will 
be  too  large  and  complex. 

4.1.3  Process  Definition 

When  the  partition  had  been  completed  the 
end  processes  had  to  be  defined.  This  was 
achieved  using  the  process  specification 
(P-3pec)  feature  of  Teamwork.  This  allows 
a  process  to  be  described  In  terms  of  text 
and  diagrams.  The  Inputs  and  outputs  are 
defined  to  this  p-spec  automatically  from 
the  dataflow  diagram.  Figure  4.3  shows  a 
low  level  dataflow  diagram  for  a  part  of 
the  control  function  of  the  EEC  and  figure 
4.4  shows  a  typical  P-Spec  that  we  shall 
come  across  again  later. 

4.2  Structural  Design 

The  task  of  structural  design  can  he 
thought  of  as  one  of  organisation.  The 
objective  Is  to  take  a  set  of  specific 
requirements  and  organise  them  into 
coherent  groups  that  will  fit  Into  the 
chosen  hardware  environment.  If  this  Is 
performed  adequately  then  the  task  of  the 
software  design  for  the  Individual 
elements  will.  In  concept,  become  trivial. 

It  Is  thus  at  this  stage  that  the  real 
world  environment  has  to  be  considered.  In 
essence  the  Yourdon  analysis  of  the 
software  requirements  has  no  knowledge  of 
the  real  time  aspects  of  the  engine 
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control  functions,  or  of  any  physical 
limitations  such  as  size  of  memory 
available. 

So  the  structural  design  was  tackled  with 
two  different  approaches.  A  bottom  up 
approach  to  create  the  structure  charts 
for  the  individual  processes,  and  a  top 
down  approach  for  the  executive  structure 
controlling  the  order  and  sequence  of 
execution  of  the  processes. 

4.2.1  Process  Structure  Charts 

The  functionality  of  individual  processes 
within  the  requirements  analysis  was 
transferred  to  a  structure  chart  format  to 
represent  the  software  design  of  each 
component.  An  example  of  a  structure  chart 
is  shown  in  figure  4.S.  These  structure 
charts  show  the  design  tree  of  the 
software  and  how  it  is  arranged  into 
various  blocks  consisting  of  functional 
modules  and  data  only  modules.  Each 
functional  modu’e  is  defined  by  a  module 
specification  (M-Spec). 

The  starting  point  for  these  M-Specs  and 
data  only  modules  is  the  P-Spec  from  the 
requirements  analysis.  The  way  in  which  a 
particular  P-Spec  is  implemented  will 
depend  upon  the  language  to  be  used  in  the 
implementation,  as  the  H-Spec  will  have  to 
directly  reflect  the  requirements  for  the 
code.  The  data  only  modules  may  be  defined 
directly  from  the  Input/output  list  of  the 
P-Spec .  figure  4.6  shows  the  structure 
chart  implementation  of  the  P-Spec  shown 
in  figure  4.4  and  figure  4.7  shows  the 
H-Spec  associated  with  this  structure 
chart. 

4.2.2  Executive  Structure  Charts 

The  executive  structure  charts  fall  into 
two  types.  Firstly  there  are  the  simple 
ones  that  reflect  the  dataflow  diagram 
breakdown.  Figure  4.8  shows  the  structure 
chart  for  the  dataflow  diagreun  shown  in 
figure  4.3.  This  structure  chart  defines 
the  calling  sequence  of  the  various 
modules  which  is  not  always  obvious,  or 
defined,  in  the  dataflow  diagram 
representation.  This  is  an  important 
feature  which  cannot  be  overlooked  even 
though  on  the  surface  it  seems  to  be  a 
trivial  task. 

The  second  kind  of  structure  chart  is  the 
o-’erall  executive  which  is  typical  of  an 
engine  control  requirement.  This  is  where 
real  world  detail  has  to  be  added  in  the 
form  of  power-up/initlalisation 
requirements  and  iteration  rates  for  the 
various  processes.  In  the  ideal  world  we 
would  be  able  to  spe.ify  the  processing 
power  requirements  to  run  all  the  software 
functions  together  at  the  highest  required 
rate  but  in  the  real  world  the  processing 
power  is  often  the  limiting  factor.  This 
means  that  we  have  to  divide  the  software 
functionality  into  elements  which  can  be 
executed  at  different  iteration  rates  so 
that  only  tne  moat  important  functions  are 
executed  at  the  highest  rate. 


Figure  4.9  shows  how  this  has  been 
achieved  for  HOLD.  This  structure  follows 
the  original  software  structure  which  is 
only  to  be  expected  as  the  hardware  is 
fixed.  The  main  split  is  between  power- 
up/initialise/base  level  functions  which 
are  one  off  or  non  time  dependent  tasks, 
and  functions  which  are  iterated  at  a 
fixed  rate.  There  are  two  rates  used,  a 
fast  level  generated  from  a  sample  rate 
clock  interrupt  and  a  slower  level 
generated  at  a  multiple  of  the  fast  level. 

It  is  this  implementation  of  the  software 
requirements  into  real  iteration  levels 
that  causes  problems  with  the  structure 
charts.  The  example  quoted  in  figure  4.4 
is  typical  of  the  problem.  The  major 
portion  of  this  function  is  executed  at 
the  slower  rate  but  certain  elements  of  it 
have  to  be  iterated  at  the  fast  rate.  This 
means  that  in  designing  the  structure 
charts  there  is  not  a  one  to  one 
relationship  between  a  P-Spec  and  a 
structure  chart. 

4.3  Formal  Methods  Integration 

In  considering  the  application  of  Formal 
Methods  to  the  HOLD  programme,  we  decided 
that  the  best  level  at  which  to  introduce 
such  techniques  would  be  at  the  P-Spec 
level. 

We  already  had  experience  of  the  use  of 
Formal  Methods,  in  terms  of  the  use  of 
static  analysis  applied  to  small  sections 
of  assembler  code.  The  next  logical  step 
was  to  move  this  process  up  a  level  to  a 
small  section  of  high  level  language  code, 
and  as  such  the  P-Spec  seemed  the  most 
appropria^o. 

There  are  many  different  functions  within 
an  engine  control  system  and  we  decided  to 
choose  a  representative  sample  of  these 
functions  for  investigation.  Four  P-Specs 
were  chosen.  Two  of  these  were  engine 
control  functions,  one  of  which  fell  into 
the  classical  control  area  and  involved 
lead-lag  compensation,  gain,  lowest  and 
highest  wins  elements  etc.,  and  the  other 
fell  into  the  logic  area  and  involved 
sequencing  functions.  The  third  P-Spec  was 
chosen  from  the  area  of  signal  validation 
involving  range,  rate  of  change  and  cross 
checks  on  a  signal.  The  fourth  function 
was  selected  from  the  area  of  the  control 
associated  with  fault  legging  and 
diagnostics. 

Our  approach  to  the  Formal  Methods 
representation  of  these  functions  was 
firstly  to  select  the  language  in  which  to 
represent  them.  There  are  several  Formal 
Methods  available  and  in  choosing  one  we 
set  out  several  criterion  on  which  we 
based  o'lr  selection.  One  factor  in  our 
choice  was  that  the  method  should  be 
widel',  accepted  and  supported.  We  wanted  a 
method  that  was  in  popular  use  by  the  rest 
of  the  industry  and  one  that  was  likely  to 
stay  in  use  for  the  foreseeable  future. 

The  method  must  also  be  supported  in  terms 
of  training  and  course  availability  and 
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ideally  would  also  have  tool  auppoct 
available  for  automation  of  the  Formal 
Method  specifications  and  proof  checking. 
For  these  reasons  we  chose  the  Vienna 
Development  Method  (VDH)  which  also  had 
the  added  benefit  of  being  the  easiest  to 
integrate  with  our  existing  systems. 

The  next  step  was  to  look  at  the 
implementation  of  the  specifications  from 
a  general  point  of  view.  This  activity  led 
to  the  formulation  of  some  general 
definitions  which  would  be  useful  in  the 
specification  of  discrete  systems.  These 
general  definitions  are  based  on  the  main 
feature  of  a  discrete  system,  that  is  the 
periodic  sampling  of  inputs  and  updating 
of  outputs. 

Such  discrete  systems  operate  cyclically, 
usually  in  response  to  a  sample  rate  clock 
interrupt,  and  prossess  state  variables 
which  determine  the  operation  of  for 
instance  timers,  fault  integrators  and 
integrators.  Formal  definition  of  the 
outputs  required  where  state  variables  are 
involved  is  beat  specified  in  terms  of  the 
History  of  the  inputs,  allowing  a  direct 
specification  of  the  requirement  to  be 
made  without  stating  the  precise 
implementation  ie  what  state  variables  are 
to  be  involved. 

The  history  of  an  input  Is  described  via  a 
map  of  cycle  number  to  the  signal's  value. 
Note  that  not  all  cycle  numbers  need  be 
represented  in  the  domain  of  the  map  since 
an  input  may  be  read,  for  instance,  on 
every  second  cycle. 

Cycle  Number  «  N; 

Activation  Cycle  Set  “  Cycle  Number-set 

Booleans  =  Cycle  Number  B; 

e.g. 

hist,  =  <l-*falBe,  2-*fal8e,  3-<true, . . . ) 
histj  »  {3-*falae,  5-*true,  7-*faloe, . . . ) 

domhisti  ^  {1,2,3,...> 
domhistj  »  (3,5,7, ... ) 

hist, (2)  <  false 
hist, (5)  “  true 
hist, (6)  is  undefined 

hist, 16  =  true  i.e.  the  value  of  hi8t,(S) 

The  application  of  this  methodology  may  be 
better  seen  when  applied  to  an  example. 
Take  for  instance  part  of  the  P-Spec 
referenced  earlier  in  figure  4.4  for  the 
control  of  the  IP  blow  of  valve  which 
states  : - 

"The  conditions  for  opening  the  IP  Blow 
Off  Valve  are  as  follows: 


Let  BOV  Cycle  be  the  set  of  cycle  numbers 
at  whicH  the  required  state  of  the  Blow 
Off  Valve  is  determined.  A  function  is 
needed  which  operates  on  the  history  of 
the  Pilot  B0V_8ignal  to  produce  a  map  from 
cycle  numEers  in  B0V_Cycle  to  a  value  of 
true  or  false:  true  if  an  output  value  of 
true  can  be  found  in 

pilot_B0V  signal_HISTORy  within  the  last 
"N"  seconds,  false  otherwise. 

BOVCheck:Booleans->Booleans 

BOVCheck(PILOT_BOV_signal_HISTORy)  4 

(c  -♦  3d  e  dom  PILOT_BOV_signal_HISTORy 

Os  c-d  s  ("N"  *  CycleFrequancy)A 

Pilot_B0V_8ignal_HIST0;\i'(d)  | 

c  (  B0V_Cycle} 

Cycle  Frequency  defines  how  many  times  per 
second  a  control  cycle  occurs.  BOV_Cycle 
defines  on  which  cycles  the  test  is 
carried  out.  Thus  with  :- 

CycleFrequency  =  100 

BOV_Cycle  »  (1,2,3, . . . ) 

Pilot  BOV  signal  «  (l->false, .  . , , 

“  “  50-*falsa, . . . , 

30000-*trua, 

30001-*fal8e, . ,  . } 

the  example  would  yield  a  result  of  :- 

(l-*falBa, .  . . , 

50-*falsa,  . . . , 

30000-*trua, 

30001-*eruo, . . . , 

30000+"N"-*true, 

30000+"N"+l-»fal8e, . . . ) 

The  VDM  specification  follows  directly  as: 

ext  rd  current_cycle  :  Cycle  Number 

rd  Pilot_BOV_Signal_HISTORy :  Booleans 
wr  Lane_A_BOV_Control_Out  :  B 

post  lane  A_BOV_Control_Out~BOVcheck 
(Pilot_BOV_Signal_HISTORy )  {current__cycle) 

Since  out  implementation  is  based  on  a 
simple  cyclic,  scheduler  what  we  require 
is  an  implementation  that  maintains  a 
Buitablu  loop  invariant.  However,  we  do 
not  want  to  implement  an  operation  which 
needs  the  complete  history  of  the 
pilot_BOV_Slgnal.  Wo  want  an 
implementation  that  on  each  cycle 
calculates  the  result  of  the  check  for 
that  cycle  based  only  on  the  value  of 
Pilot_BOV_Signal  for  that  cycle  and  a 
small  amount  of  additional  state. 


(1.0)  Immediately  on  receipt  of  a 
Pilot_^BOV_Signal,  and  held  for  a 
period  of~"N"  seconds  after  the 
Piiot_BOV_Signal  is  removed." 
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The  obvious  representation  to  use  for  the 
additional  state  is  a  counter  whose  value 
will  be  how  many  cycles  ago  the 
Pilot_BOV_Signal  was  last  true.  This 
counter  will  be  called  BOV_t imer_count . 
in  order  to  place  a  bound  on  the~value  of 
this  counting  when  we  reach  the  smallest 
integer  which  is  larger  than 
N*CycleFrequency.  We  will  call  this  value 
BOV_End_Count . 

BOV_End  Count:N=round(N  *  CycieFrequency-f 
0.5) 

After  identifying  the  loop  invariant  we 
can  arrive  at  the  specification  of  an 
operation  which  calculates  the  result  of 
the  blow  off  valve  check.  The  role  of 
this  operation  is  to  re-establish  the  loop 
invariant  for  each  cycle. 

ext  rd  current_oycle  :  CycleNumber 

rd  Pilot_BOV_Signal_HISTORy iBooleans 
wr  lane_A_BOV_Control_Out  :  B 
wr  BOV_timer_count  ~  :  N 

pre  0  s  B0V_timer  count  S  BOV  End_CountA 
-(3  d  «  dom  Pllot_BOV_signal_HISTORY. 
current_cycle-l-BOV_trmer_count<  d  s 
ourrent~cyclo  -1  ~  " 

A  Pilot~BOV  Signal  HISTOr.y(d))  A 
BOVChecic  ( P  iTot_BOV“ 
Signal_HISTORyy(curtent_cycle-l) 

"  (BOV~timer_count<BOV_End_Count  A 
Pilot_BOV  Signal_HISTORy (ourrent_cycla 
-l-BOV_timer-count) )  “ 

post  lane  A  BOV  Control  Out  - 

BOVChecTc(PiIot_BOV_Signal_HISTORy) 
(ourrant_cycle7A  “  ~ 

0  S  BOV  timer  countsBOV  End  Count  A 
-(3  d  e”dom  PTlot_80V_sIgnaT_H:STORy. 
current_cyole-BOV~timer_count 
<dscurrent_cycle  ~  ~ 

A  pilot  BOV-Signal  HIST0RY{d))  A 
BOVCliecK  ( P  i  lot_BOV“s  igna  l_HISTORY ) 
(curront_cycloT  ”  ~ 

••  ( 80V_t  iraer_count<BOV_End_CountA 
Pilot_BOV_Signal_HISTORY(current_cycle 
-B0V_t imer_county ) 

If  we  assume  that  there  is  a  some 
mechanism  to  maintain  the  relationship: 

Pilot_BOV_Signal  = 

Pilot_BOV_Signal_HISTORY( current  cycle) 

tnen  the  implementation  of  the  operations 
will  only  need  to  refer  to  Pilot_BOV- 
aignal,  and  in  fact  the  variables 
Pilot_BOV-Signal_HISTORY  and  current_cycle 
will  not  appear  anywhere  in  our  executable 
code  (such  variables  are  referred  to  as 
proof  variables).  The  mechanism  that 
maintains  the  relationship  is,  of  course, 
the  input  routines. 

From  this  VDM  description  the  code  may  be 
produced,  but  before  this  step  can  be 
explained  we  have  to  look  at  the  Ada 
programming  environment. 

4 . 4  Programming  Environme.it 

In  considering  the  application  of  Ada  to  a 


real  time  engine  control  application  there 
were  two  main  areas  that  we  had  to 
investigate.  Firstly  thers  were  the  safety 
aspects  of  the  language  and  secondly  there 
were  the  timing  implications. 

4.4.1  Safety  Critical  Language  Features 

In  the  use  of  any  language  there  are 
generally  features  of  that  language  that 
are  not  desirable  in  a  safety  critical 
engine  control  software  systems.  As  stated 
earlier  the  failure  of  the  software  to 
complete  a  function  is  a  serious  error  not 
merely  an  inconvenience.  It  is  of  critical 
importance,  therefore,  that  any  function 
in  the  software  has  an  explicit  entry  and 
exit  condition.  For  this  reason  loop 
constructs  of  the  type  DO-UNTIL,  DO-FOR 
and  DO-WHILE  are  avoided  especially  where 
the  loop  parameter  is  determined  at  the 
run  time  of  the  system.  For  a  similar 
reason  the  use  of  GO-TO  type  constructs 
should  be  avoided  as  they  permit  ad-hoc 
entry  to  and  exit  from  functions. 

Another  major  feature  of  safety  critical 
engine  control  systems  is  that  in  general 
the  hardware  environment  is  composed  of  a 
custom  made  unit.  This  means  that  any 
software  language  used  to  program  these 
units  must  have  the  ability  to  interface 
with  the  uniqtie  hardware  of  the  unit.  This 
is  available  with  Ada,  and  with  other 
languages,  by  means  of  an  interface  with 
assembly  language  components.  The  hardware 
constraints  also  limit  in  a  system  the 
amount  of  memory  available  and  for  this 
reason  it  is  preferable  to  know  in  advance 
how  much  storage  is  required.  Thus 
features  which  dynamically  allocate  memory 
at  run  time  must  be  avoided.  Ideally  all 
the  memory  should  be  statically  defined  at 
compile  or  link  time,  or  in  the  case  of  a 
stack  for  example  the  bounds  of  the  memory 
requirements  should  be  calculable. 

4.4.2  Time  Critical  Language  Features 

A  typical  engine  control  system  runs  at  an 
iteration  rate  in  the  region  of  20 
milliseconds,  the  time  being  chosen  to 
achieve  satisfactory  engine  control 
response.  Thus  time  is  critical  in  an 
engine  control  environment  as  there  is  no 
option  available  to  increase  the  cun  time 
of  the  software.  For  this  reason  the 
efficiency  of  the  language  is  of  prime 
importance.  From  experience  we  knew  that 
the  run  time  system  was  going  to  be  an 
Important  area  to  investigate,  not  only  in 
respect  of  Ada  itself  but  also  in  respect 
of  the  particular  compiler  selected. 

We  required  a  cun  time  system  that  could 
provide  a  simple  and  quick  interrupt 
transfer  mechanism  without  the  use  of 
tasking  because  of  the  time  response 
associated  with  this  feature  of  Ada. 

Another  feature  of  Ada  that  we  wished  to 
avoid  was  the  use  of  exception  handlers. 
The  main  source  of  exceptions  in  an  engine 
control  system  is  due  to  integer  overflow. 
As  integer  operations  are  widely  used  this 
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would  need  in  theory  an  exception  handler 
for  each  operation  as  the  result  required 
would  be  different  in  each  case.  This 
approach  would  place  a  unacceptable 
overhead  on  the  execution  time  of  the 
code.  The  preferred  method  is  to  design 
out  or  protect  against  overflow 
conditions,  so  that  exception  handlers 
become  redundant. 

4.4.3  Compiler  Selection  and  Restrictions 

As  a  result  of  the  requirements  set  out  in 
the  previous  two  sections  we  selected  the 
Ada  compiler  from  SD-Scicon  since  it  has  a 
minimal  run  time  system,  which  could  also 
be  tailored  to  our  own  individual 
requirements.  The  selection  was  also 
influenced  by  the  needs  to  operate  on  our 
own  computer  system  in  terms  of 
target/host  configuration. 

In  considering  the  possible  need  to  apply 
restrictions  to  the  Ada  language  we  looked 
for  a  way  of  providing  a  safe  sub-set  of 
the  language.  Ideally  we  required  some  way 
to  automatically  test  code  for  illegal 
construct  usage.  There  is  a  very  limited 
set  of  products  in  this  field  but  one 
which  fitted  not  only  our  requirements  for 
a  safe  sub-set,  but  also  our  needs  in  the 
integration  of  Formal  Methods,  was  SPARK 
(SPADE*  Ada  Run-time  Kernel) . 

SPARK  is  a  tool  which  checks  Ada  source 
code  for  a  variety  of  restricted  features 
and  issues  warnings  if  any  code  violates 
these  conditions.  The  tool  also  performs 
tasks  associated  with  the  static  analysis 
of  the  code.  This  provides  flow  cheeking 
of  the  code  as  well  as  verification 
condition  generation  and  proof  checking. 
These  last  two  elements  fitted  well  with 
the  integration  of  Formal  Methods  in  the 
generation  of  the  code.  We  could  thus  use 
the  VOH  specifications  to  generate  pre  and 
post  conditions  in  the  Ada  code  which  we 
could  then  prove  using  SPARK. 

5.  INITIAL  CONCLUSIONS 

At  present  the  HOLD  programme  is 
approximately  75t  complete.  The  analysis 
and  capture  of  the  software  requirements 
and  the  software  design  phases  are 
essentially  complete.  The  main  activities 
at  the  moment  are  the  coding  and  the 
generation  of  the  VDM  specifications. 

5. 1  Software  Reouirementa  Document 

The  analysis  of  the  software  requirements 
document  using  the  Yourdon  methodology  has 
resulted  in  a  very  easy  to  read  document. 
The  way  that  the  requirements  are  split 
down  into  finer  and  finer  detail  means 
that  at  each  level  of  the  hierarchy  of 
dataflow  diagrams  a  comprehensible  amount 
of  information  can  be  given.  It  must  be 
remembered,  however,  that  the  methodology 
only  serves  as  a  tool  to  represent  the 
software  requirements,  it  only  helps  to 
specify  the  requirements  in  so  far  as 
laying  them  out  in  a  clear  manner  so  that 


xas.-'i  can  be  communicated  easily. 

5.2  Design  Description  Document 

As  is  the  case  with  the  software 
requirements,  the  use  of  structure  charts 
generated  from  the  dataflow  diagram 
breakdown  has  provided  a  clear  description 
of  the  software  design.  The  main  problem, 
as  with  all  systems,  is  that  of  the 
transition  from  what  is  required  to  how  it 
is  to  be  implemented.  The  addition  of 
implementation  dependent  features  at  the 
software  design  stage  can  obscure  the  flow 
of  information  from  the  analysis  to  the 
design  phase.  This  problem  can  be 
overcome,  however,  if  the  analysis  is 
performed  with  the  implementation  in  mind. 
In  the  life  cycle  of  any  project  there  is 
rarely  just  one  iteration  around  the  loop 
from  requirements  to  design  to  code.  In 
practice  this  loop  is  iterated  around  many 
times.  The  software  requirements  at  the 
beginning  of  a  project  are  seldom  complete 
and  develop  over  the  life  cycle  of  the 
project.  In  this  way  the  Yourdon  breakdown 
may  serve  initially  as  a  definition  of  the 
requirements  but  as  time  progresses  this 
definition  can  be  developed  so  that  the 
requirements  are  broken  down  in  a  manner 
which  suits  the  chosen  implementation. 

This  will  lead,  eventually,  to  a  closer 
one  to  one  relationship  with  the  design 
phase  and  thus  simplify  the  software 
development  process. 

5.3  Ada  Run  Time  System 

Our  work  done  on  the  assessment  of  run 
time  systems  suitable  for  this 
application,  as  part  of  the  selection  of 
an  Ada  compiler  has  shown  that  the  area  of 
"bare  micro"  targets  is  being  addressed  by 
compiler  vendors.  As  recently  as  five 
years  ago  it  would  have  been  impossible  to 
purchase  anything  other  than  a  large  run 
time  system  aimed  at  a  large  computer 
system  target.  Now  more  attention  is  being 
focused  on  almost  "bare  micro"  target 
systems.  The  fact  that  we  have  been  able 
to  take  an  off  the  shelf  system,  albsit 
with  some  tailoring,  is  testimony  to  this 
develo]pment.  Using  this  supplied  system  we 
have  so  far  developed  a  bare  run  time 
system  (interrupt  servicing  and  teat  port 
communication)  which  is  working  in  the 
target  unit. 

The  tim.ing  and  memory  utilisation  of  this 
system  has  been  shown  to  be  acceptable  for 
engine  control  applications. 

5 . 4  Comparisons  with  Traditional 
Methodology 

The  traditional  development  of  software 
has  relied  on  English  language 
descriptions  for  the  software  requirements 
and  design.  Whilst  this  is  still  true  in 
part  for  HOLD,  as  most  of  the  P-Specs  are 
still  in  English  language,  the  application 
of  the  new  methodology  has  served  to 
present  the  requirements  and  design  in  a 
clearer  form.  The  work  in  hand  at  present 
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on  the  application  of  Formal  Methods  to 
the  P-Specs  will  show  whether  we  can 
replace  the  English  language  descriptions 
with  a  rigorous  mathematical  description. 

6.  FUTURE  WORK  OM  HOLD 

Once  the  work  of  completing  the  coding  and 
Formal  Methods  implementation  of  the 
selected  P-Specs  is  complete  the  main  task 
of  qualitative  and  quantitive  assessment 
can  begin. 

We  have  already  been  able  to  assess  the 
implication  of  using  Vourdon  and  the 
effects  of  the  Ada  run  time  system  and 
both  have  shown  positive  results  for  the 
future  of  engine  control  software 
development.  The  areas  that  have  yet  to  be 
assessed  in  the  future  are  threefold. 
Firstly  there  is  the  assessment  of  the  Ada 
code  itself.  Comparisons  will  be  made 
between  the  Ada  and  original  LUCOL 
Software  code.  These  comparisons  will 
address  not  only  the  efficiency  of  the  two 
languages,  run  time,  memory  utilisation 
etc.  but  also  the  speed  and  ease  of  code 
development.  Secondly  there  is  the 
analysis  of  the  effects  that  the  use  of 
Formal  Methods  will  have  on  software 
development.  Our  work  to  date  has  shown 
that  application  of  Formal  Methods  should 
lead  to  unambiguous  specifications. 
However,  the  practical  application  of  such 
methodoiogius  is  not  easily  attainable  by 
engineers,  because  of  the  highly 
mathematical  nature  of  the  system  plus  the 
fact  that  experience  of  their  use  in  real 
word  situations  of  this  type  is  extremaly 
limited.  Thirdly  there  is  the  aspect  of 
validation  of  the  system  to  be  considered. 
In  the  past  critical  engine  control 
software  has  been  verified  down  at  the 
level  of  the  target  coda  resident  In  the 
target  environment.  Using  Formal  Methods, 
for  example,  will  allow  the  mathematical 
proof  that  a  piece  of  Ada  code  meets  its 
formal  specification.  This  proof  relies  on 
the  Ada  compiler  producing  correct  code. 
Whether  this  is  an  acceptable  system  for 
validating  software  has  yet  to  be 
assessed. 

6. 1  Conclusions  of  Proiect 

The  work  completed  so  far  on  the  HOLD 
Project  has  emphasised  that  the 
application  of  Ada,  formal  notations  and 
CASE  tools  to  the  flight  safety  critical 
military  gas  turbine  FAOEC  brings 
particular  problems. 


However,  we  are  also  beginning  to  see  the 
potential  benefits  within  the  total 
process  that  the  application  of  a 
structured,  system  level  approach  can 
bring.  It  appears  that  if  such  an 
approach  is  applied  throughout  the 
process,  from  requirements  capture  through 
to  implementation,  that:- 

i)  the  likelihood  of  specification 
errors  will  be  reduced. 


ii)  the  likelihood  of 
misinterpretation  of  functional 
requirements  will  be  reduced, 

iii)  the  interface  responsibilities 
between  the  various  partners 
should  be  more  easily  identified, 

iv)  The  functional  interface  between 
the  elements  of  the  system  should 
be  more  easily  identified, 

V)  programs  monitoring  and  the 

process  to  clear  the  system  for 
flight  should  be  less  difficult  to 
manage, 

vi)  the  whole  process  will  be  more 
effective  in  the  use  of  all 
resources  deployed. 

HOLD  will  enable  the  military  aero-gas 
turbine  community  to  make  a  positive 
contribution  to  the  general  understanding 
of  the  topics  that  are  being  studied.  We 
will  more  clearly  understand  where  it  is 
appropriate  to  use  generalised  techniques 
and  where  we  must  be  concerned  because  of 
Che  application  specific  constraints. 

Where  we  do  identify  clearly  that  a  FADEC 
does  require  particular  considerations 
then  we  will  be  able  to  present  cogent 
reasons  for  those  considerations  and 
influence  future  standards  and  working 
practices. 

HOLD  will  improve  our  ability  to  identify 
prograirme  technical  and  financial  risk  and 
hence  improve  UK  HOD (PE) 's  ability  to 
procure  functionally  capable  systems  on- 
time  and  on-cost. 
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Figure  4.1  CONTEXT  DIAGRAM  DFD 
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Figure  4.2  LANE  A  FUNCTIONAL  BREAKDOWN  DFD 


Figure  4.3  OPEN  LOOP  CONTROL  DFD 
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NAME: 

1J./.1 1;1 

TITLE: 

PERFORM  IP  BOV  CONTROL  TASK 

INPUT/OUTPUT 
Pto_sclected :  data_in 
Pilot_BOV_signal :  data_in 
lane_A_BOV_control_out :  data_out 

BODY: 

Purpose. 

/I 

Tb  control  the  operation  of  the  IP  Blow  Off  Valve. 

Function. 

The  conditions  for  opening  the  IP  Blow  Off  Valve  arc  as  follows: 

1.0  Immediately  on  the  receipt  of  a  Pi]ot_BOV_signal,  and  held  for  a 
period  of  ”N”  seconds  after  the  signal  is  removed. 

OR 

2.0  TTie  following  Pressure  conditions  are  achieved 
Pto  <  X  Kpa  Pto  decreasing 
Pto  <  y  Kpa  Pto  increasing 


Figure  4.4 


Figure  4.5A  STRUCTURE  CHART  EXAMPLE 


1  STRUCTURE  CHART  EXPLANATION 


Introduction 

Each  structure  chart  is  composed  of  an  arrangement  of  various  graphic  symbols  these  symbols  are 
described  below. 

1.1  Module  MSPEC 

Modules  A  B  and  C  are  Plain  modulcs.they  represent  some  detailed  processing  activity  the  name  of 
the  module  relates  to  the  nature  of  the  activity  occurring  within  the  module. 

Associated  with  each  module  is  an  MSPEC  which  details  the  procedural  aspects  and  actions  performed 
by  the  module. 

1.1.1  Data  Only  Module 

The  Data  Only  Module  represents  Global  data,  that  is  data  used  Globally  throughout  the  software, 
and  each  data  only  module  can  represent  a  single  instance  of  an  item  of  data,  or  an  aggregate  of  such 
items  stored  m  a  particular  location. 

1. 1.1.1  Offsheet  Connector 

The  Offsheet  Connector  is  used  to  represent  the  existence  of  a  further  structure  chart,  and  allows 
decomposition  of  more  complex  charts  mto  simpler  subordmate  structure  charts. 

1. 1.1.2  Data  Couple 

The  data  couple  represents  data  flow  within  the  structure  chart.they  mi  ist  be  attached  to  an  invocation. 
The  couple  can  represent  Global  or  Local  data,  the  direction  of  the  anow  represents  the  direction  of 
the  flow. 

1.1.1  J  Control  Couple 

The  control  couple  represents  control  flow  within  the  structure  chart.they  must  be  attached  to  an 
invocation.  The  couple  can  represent  Global  or  Local  control,  the  direction  of  the  arrow  represents 
the  direction  of  the  flow. 

1.1.1.4  TVansaction  Centre 

Represents  some  decision  making  process,  such  as  conditional  mvocation  of  a  subordmate  module. 

1.1.1.5  Hat 

Represents  Ifextual  inclusion,  that  is  the  body  of  the  MSPEC  and  the  action  performed  by  it  is  meant 
to  be  included  withm  the  calling  module. 

Ttxtual  mclusion  only  occurs  between  plain  modules,  and  does  not  occur  between  offshee*  connectors 
and  or  data  only  modules. 

1. 1.1.6  Invocation 

The  invocation  line  is  ^mbolic  of  a  call  from  a  module  to  other  symbolic  items. 

It  should  be  noted  that  the  philosophy  adopted  throughout  this  document  is  that  only  modules  can 
invoke  other  symbolic  items. 

The  offsheet  connector  is  used  to  connect  invocations  from  a  module  to  another  structure  chart,  in 
this  case  the  interface  between  the  corresponding  connectors  on  each  sheet  must  match  exactly. 


Figure  4.B 


The  precedence  of  invocation  is  Left  to  Right  and  Down,  with  reference  to  Fig  1. 
Offsheet  connector  1  with  a  control  parameter  invokes 


Module  A 

The  module  performs  its  required  operation 


Module  A 
Invokes 


Module  B 

The  invocation  is  terminated  with  a  hat, 

The  module  performs  its  required  operation 
Module  A 
Invokes 

Module  C  which  invokes  (reads  or  writes)  from  the  data  only 
modules  X  and  Y,  performs  some  action  and  then  returns 
the  data  couple  Z 


Module  A  conditionally  invokes 

Offsheet  connector  D  which  performs  some  action  . 


Figure  4.5C 


igure 


NAME: 

IP_BOV_Controi:12 

TITLE: 

IP  Blow  off  valve  control  procedures 

PARAMETERS: 

LOCALS: 

Pre_condition_X 

Pre_condition_Y 

Ptojast 

Pto_limit_l 

PtoJimit_2 

GLOBALS: 

Pto_seIected :  data_m 
Pilot_BOV_signal :  data_in 
lane_A_BOV_control_out :  data_out 

BODY: 

Purpose/Description 

IP_BOV_Control  is  a  subordinate  MSPEC  on  the  Structure  Chart  of  the  same  name. 
Ii  is  invoked  via  the  offsheet  connector  of  the  same  on  the  Structure  Chart 
Open_Loop_ControI. 

1) Read  in  the  Globals  listed  above  in  the  GLOBALS  list  as  datajn. 

2) Evaluate  the  conditions  for  opening  the  IP  BOV. 

2.1  Pressure  Limits. 

Pto_Iimit_l  -  X  Kpa 
PtoJimit_2  -  y  Kpa 

2.2  Evaluate  Pre_condition_X 

If  ((Pto_selected  <  Pto_limit_l)  and  (Pto_selected  <  Pto_Iast)  then 
set  Pre_condition_X  -  TRUE 
else 

set  Pre_condition_X  -  FALSE 

2.3  Evaluate  Pre_condition_Y 

If  ((Pto_selected  <  Pto_limit_2)  and  (Pto_selected  <  PtoJast)thcn 
set  Pre_condition_Y  -  TRUE 
else 

set  Pre_condition_Y  -  FALSE 

2.4  Determine  new  condition  for  tane_A_BOV_control_out 

If  (Pre_condition_X  or  Pre_condition_Y  or  Pilot_BOV_signal)  ■=•  TRUE  then 
set  lane_A_BOV_control_out  -  TRUE 
else 

set  lane_A_BOV_control_out  »  FALSE 

3)  Ptojast  "  Pto_selected 

4)  Write  out  the  Global  lane_A_BOV_control_out 


Figure  4.7 


Figure  4.9  TOP  LEVEL  STRUCTURE  CHART 
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COMMON  ADA  MISSILE  PACKAGES 
(CAMP) 

Barry  E.  Mullins 
Armament  Directorate 
Wright  Laboratory 
WL/MNAG 

Eglin  AFB,  Florida  32642>6434 


Abstract 

The  words  "software  crisis"  should  not  be  new 
to  anyone  managing  a  program  that  involves 
software.  A  shortage  of  skilled,  software  personnel 
is  adversely  affecting  the  development  and 
subsequent  maintenance  of  today’s  and  future 
weapon  systems.  The  Department  of  Defense 
(DOD),  as  well  as  industry,  acknowledge  this  crisis 
and  are  taking  bold  measures  to  alleviate  it.  The 
Common  Ada  Missile  Packages  (CAMP)  program  is 
one  such  measure  the  DOD  has  undertaken  to  ease 
the  crisis  via  a  high-payoff  remedy  -•  reuse  of  real¬ 
time  embedded  (RTE)  software.  CAMP  is  a 
pathfinding  effort  designed  to  investigate  the 
feasibility  of  RTE  software  reuse  by  actually 
developing  reusable  Ada  parts,  compiler 
benchmarks  and  a  parts  engineering  system  (PES). 
This  paper  describes  the  genesis  of  CAMP, 
structure  of  the  CAMP  program,  evaluation  results 
and  CAMP  products.  McDonnell  Douglas  Missile 
Systems  Company  developed  the  CAMP  products 
under  the  sponsorship  of  the  Armament 
Directorate,  Wright  Laboratory  at  Eglin  Air  Force 
Base,  Florida. 

'The  Software  Crisis 

The  amount  of  software  required  to  operate 
weapon  systems  over  the  past  30  years  has  grown 
tremendously.  Where  earlier  F-4  fighter  jets  had  no 
software  systems,  today’s  B-1  bomber  is  saturated 
with  well  over  1  million  lines  of  code.  This  is  just 
one  example  of  the  insatiable  demand  for  complex 
software  systems  which  are  typically  the  mqjor  cost 
driver  of  weapon  systems.  This  demand  has  not 
been  matched  by  the  education  and  acquisition  of 
skilled  software  developers  and  maintainers.  This 
imbalance  ultimately  resulted  in  the  use  of  out¬ 
dated  software  methods  and  tools  being  applied  to 
highly  complex,  sophisticated  applications  thus 
leading  to  sometimes  inferior,  unreliable  weapon 
systems  being  delivered  late  and  almost  always 
over  budget. 

In  1983,  the  Air  Force  Software  Technology 
for  Adaptable  Reliable  Systems  (STARS)  Task 
Force  published  a  report  on  the  software  crisis  and 
possible  solutions.  The  report  recommended 
software  reuse  to  ease  current  software  problems. 
Software  reuse  by  itself  is  not  the  panacea  to  the 
software  'risis  but  seems  to  offer  tremendous 
returns.  Potential  benefits  include  increased 
software  development  productivity  of  more  reliable 
software  systems  and  more  efficient  use  of  software 
engineering  expertise.  Furthermore,  in  1983,  the 
DOD  mandated  the  use  of  the  Ada  programming 
language  (ANSI/M1L-STD-1815A)  in  all  new 
embedded  systems.  Since  the  constructs  of  the  Ada 


language  are  extremely  amenable  to  reuse,  the  Air 
Force  Armament  Laboratory  (now  the  Armament 
Directorate,  Wright  Laboratory)  initiated  the 
CAMP  program  to  investigate  software  reuse  for 
conventional  missiles  using  Ada  (what  else?). 

The  CAMP  Solution 

Although  software  reuse  has  been  practiced 
with  varying  levels  of  success  prior  to  the  STARS 
report  and  the  Ada  mandate,  it  was  almost  always 
ad  hoc  reuse  and  the  application  domains  were 
typically  not  as  constrained  by  size  and  speed  as 
found  in  the  conventional  missile  arena.  It  should 
also  be  noted  that  prior  to  Ada,  programming 
languages  were  not  equipped  with  the  necessary 
facilities  to  directly  support  software  reusability  nor 
were  they  as  highly  standardized  (i.e.,  supporting 
software  transportability  between  platforms). 

The  CAMP  program  was  designed  to  address 
these  limitations.  C^P  focused  on  three  primary 
areas  as  they  relate  to  operational  missile  flight 
software;  (1)  investigate  the  feasibility  and 
applicability  of  software  reuse;  (2)  design  and 
develop  reusable  Ada  parts,  Ada  compiler 
benchmarks  and  a  supporting  environment  for  the 
Ada  parts;  and  (3)  refine,  productize  and  transition 
the  technology.  To  satisfy  these  goals,  CAMP  was 
performed  in  three  separate  contracts  all  competed 
and  won  by  McDonnell  Douglas  Missile  Systems 
Company.  The  contracts  satisfied  a  particular 
phase  of  the  program  and  were  therefore  called 
phases. 

CAMP-1;  FeaaihUity  Study 

The  first  phase  of  the  CAMP  program.  Phase 
1  (CAMP-1),  began  in  September  1984.  CAMP-1 
was  a  one  year  feasibility  study  designed  to 
determine  the  scope  of  commonality  among  missile 
flight  software.  Assuming  sufficient  commonality 
existed,  the  top-level  design  for  common  parts 
would  be  developed.  Also,  the  feasibility  and  value 
of  automating  the  process  of  building  these  software 
systems  using  parts  was  to  be  investigated. 

Before  further  discussion,  it  is  important  to 
fully  understand  what  constitutes  a  CAMP  part. 
The  CAMP  program  used  the  following  definition;  A 
part  is  an  Ada  software  package,  subprogram  or 
task  that  must  be  usable  in  a  stand-alone  fashion 
(i.e.,  does  not  depend  on  external  code  for  proper 
execution).  However,  parts  may  "with"  other  parts. 
The  goal  of  CAMP-1  was  to  develop  elementary, 
flexible  parts  which  provide  a  useful  function  to 
more  than  one  application  while  maintaining  run¬ 
time  efficiency. 
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Domain  Analysis 

The  feasibility  study  included  a  domain 
analysis  that  attempted  to  identify  common 
operations,  objects  and  structures  within  a  bounded 
domain.  Although  a  domain  analysis  is  expensive 
and  laborious,  it  is  imperative  to  verify  domain 
commonality  exists  before  any  attempt  is  made  at 
designing  reusable  parts.  To  attempt  parts 
development  without  a  domain  analysis  would  be  a 
waste  of  effort  since  the  resulting  parts  would  not 
offer  true  commonality  within  the  application  area. 

Ten  existing  missile  systems  were  included  in 
the  domain  analysi  which  included  at  least  two 
missiles  from  the  following  classes:  air-to-air,  air-to- 
surface,  surface-to-air  and  surface-to-surface.  By 
studying  documentation  and  source  code  for  the 
missiles,  sufficient  commonality  was  verified  to 
warrant  the  design  of  parts. 

During  the  domain  analysis  it  was  discovered 
that  missile  domain  parts  can  be  properly  separated 
into  two  types  -  domain  dependent  and  domain 
independent.  Domain  dependent  parts  are 
applicable  only  to  the  missile  flight  software 
domain.  Domain  independent  parts  can  be  used  in 
other  domains  with  few,  if  any,  changes.  An 
example  of  domain  independent  parts  include  the 
mathematical  parts  which  arc  essential  to  missile 
Software  but  also  may  be  used  in  other  areas. 

CAMP-1  successfully  demonstrated 
commonality  existed  within  the  missile  domain.  A 
total  of  219  reusable  parts  were  identified.  The 
requirements  and  top-level  design  of  each  part  were 
documented,  and  a  software  parts  taxonomy  was 
created  to  facilitate  parts  classification  and 
organisation.  Part  complexity  ranged  from  simple 
mathematical  functions  to  complex  processes  and 
structures. 

Parts  Engineering  System  and  Cataloging 
Scheme 

The  development  of  efficient  reusable  parts  is 
a  major  milestone  in  the  fight  against  the  software 
crisis.  However,  parts  alone  are  r.ot  the  answer; 
tools  must  be  developed  to  organize,  index,  describe 
and  reference  the  parts  to  fully  exploit  software 
reuse.  Therefore,  substantial  effort  was  invested  in 
the  CAMP  tools.  In  CAMP-1  a  top-level  design  for  a 
Parts  Engineering  System  (PES)  was  developed. 

The  ultimate  goal  of  the  PES  was  to  facilitate 
storage  and  retrieval  of  relevant  software  parts  for 
use  on  other  projects  while  increasing  the 
productivity  of  the  parts  user.  The  development  of 
the  PES  included  the  investigation  of  cataloging 
schemes  and  documentation  requirements.  The 
actual  capabilities  of  the  PES  are  discussed  in  the 
CAMP-2  section. 

The  candidate  cataloging  scheme  for  CAMP 
was  studied  in  great  detail.  Realizing  the  role 
effective  catalogs  play  in  successful  software  reuse, 
the  study  included  research  into  existing  catalog 
scheiues  and  philosophies.  Without  an  adequate 
cataloging  scheme,  the  identification  of  particular 
software  parts  becomes  cumbersome  at  best  and  in 
some  instances  virtually  impossible.  A  successful 


cataloging  scheme  must  include  sufficient 
information  to  determine  applicability  of  parts  to 
the  user’s  domain/problem  and  efficiently  retrieve 
parts  without  burdening  the  user  with  too  much 
data.  An  overload  of  information  can  be 
counterproductive  and  ultimately  lead  to  the  failure 
of  the  system  due  to  lack  of  use.  Figure  1  displays 
the  catalog  attributes  utilized  in  the  CAMP  PES 
catalog. 

A  usable  catalog  system  must  take  yet 
another  step  to  ensure  success  of  the  software  reuse 
effort  -  complete  documentation  of  the  software 
parts.  Every  part  must  be  thoroughly  documented 
with  standard  data  to  provide  future  users  with 
necessary  decision-making  information.  A  standard 
form  should  be  developed  for  the  catalog  entry  effort 
to  ensure  all  necessary  information  is  supplied 
when  a  part  is  entered  into  the  catalog.  In  the 
future,  on-line  data  entry  may  eliminate  the  need 
for  such  a  form. 
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Figure  1  CAMP  PES  Catalog  Attributes 


Automated  Software  Generation  Using  Parts 

To  facilitate  the  development  of  missile 
software  systems,  a  study  into  the  feasibility  and 
value  of  developing  an  automated  moans  of 
generating  software  using  existing  parts  was 
performed. 

The  concept  of  automatic  software  generation 
is  not  new.  In  fact,  from  the  dawn  of  machine 
language,  researchers  were  devising  mechanisms  t 
automate  software  generation  by  abstractio 
coding.  At  the  time,  they  called  this  assembly 
language.  As  software  technology  advanced,  so  did 
researchers’  expectations.  They  continued  to  expect 
automatic  software  generation  capabilities  -  hence 
the  birth  of  higher  order  languages.  Today,  the 
quest  is  turning  towards  VHOL  (Very  High  Order 
Languages).  VHOL  allows  the  user  to  enter 
specifications  and  requirements  at  a  high  level  of 
abstraction. 

The  reward  for  automating  software 
generation  is  low-cost,  quality  software  via  reduced 
development  time  and  cost.  This  is  attained  by 
requiring  less  detailed  design  knowledge  of  software 
developers.  Thus,  a  domain  engineer  would  be  able 
to  directly  develop  a  software  system  by  inputting 
his  domain  requirements  into  the  generation 
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system  thereby  bypassing  the  software  engineer 
altogether  resulting  in  overall  cost  savings.  These 
savings  are  enhanced  by  the  use  of  existing  parts. 
In  addition  to  the  cost  savings,  the  parts  offer 
greater  reliability  since  they  have  been  previously 
tested. 

After  studying  various  automatic  software 
generation  systems  available  at  the  time, 
specification  techniques,  methods  of  operation,  text 
generation  and  expert  system  assistance,  the  CAMP 
"constructors"  were  designed.  Constructors  are 
software  templates  that  when  combined  with  user 
input  to  customize  the  template  results  in  the 
generation  of  complex  software  components. 
Constructors  are  supported  by  the  PES  expert 
system  and  a  limited  natural  language  interface. 

CAMP>2:  Development  Effort 

The  beginning  of  CAMP’s  second  phase 
(CAMP-2)  coincided  with  the  conclusion  of  CAMP-l 
in  September  1985  and  finished  32  months  later. 
The  primary  goal  of  CAMP-2  was  to  complete  the 
development  of  the  CAMP  software  and 
demonstrate  CAMP  technologies  in  a  credible, 
demanding  application.  This  included  the 
development  and  testing  of  the  reusable  Ada  parts, 
the  parts  engineering  system  and  Ada  compiler 
benchmarks  and  the  use  of  this  software  to  build  an 
"11th  missile"  (so  named  because  it  was  not  in  the 
original  domain  study  from  which  the  parts  were 
generated). 

Development  and  Testing  of  CAMP  Parts 

The  requirements  and  designs  developed 
during  CAMP-1  formed  the  foundation  of  the  actual 
part  implementations  during  CAMP-2.  All  219 
parts  identiHed  during  CAMP-1  were  coded,  tested, 
and  documented  during  this  phase.  While 
developing  these  parts,  an  additional  235  parts 
were  identified,  designed,  coded  and  tested  during 
CAMF-2  boosting  the  total  number  of  parts  to  454. 

One  of  the  design  goals  for  the  parts  was  to 
keep  them  simple  thus  facilitating 
understandability  and  reuse.  Part  simplicity  was 
enhanced  by  keeping  their  size  small.  The  parts 
ranged  from  10  to  100  Ada  statements.  Another 
way  to  enhance  part  simplicity  was  to  ensure  the 
granularity  of  the  parts  were  at  the  lowest  possible 
level.  In  other  words,  the  missile  tasks  were  broken 
down  into  the  lowost  possible  functions  while 
maintaini.it,'  understnudability  of  the  part.  Also, 
complex  parts  were  developed  using  a  combination 
of  simple  parts. 

Another  factor  leading  to  the  successful  reuse 
of  software  is  adequate  documentation.  The  CAMP 
parts  were  documented  extensively.  Unfamiliarity 
of  the  parts  is  the  primary  purpose  for  this 
documentation.  A  new  user  of  the  CAMP  parts  will 
be  unfamiliar  with  them  and  require  tremendous 
information  on  their  operation.  Also,  CAMP  parts 
use  Ada's  "generic  units"  which  may  be  foreign  to 
most  users.  The  documentation  provides  the 
necessary  information,  including  samples,  to 
properly  instantiate  and  use  the  parts. 


During  parts  development,  effort  data  were 
carefully  tracked  to  determine  productivity.  To 
ensure  an  accurate  and  fair  comparison  with  other 
efforts,  two  metrics  were  used  to  calculate  the  size 
of  the  parts  ~  lines  of  code  and  Ada  statements.  A 
line  of  code  was  defined  as  any  line  in  the  source 
code  file  which  contained  all  or  part  of  an  Ada 
statement.  An  Ada  statement  count  is  simply  the 
niunber  of  Ada  statements  in  a  source  file  (i.e.,  the 
number  of  semicolons).  Figure  2  illustrates  the 
total  size  of  the  CAMP  parts.  The  figure  also 
reveals  the  enormous  amount  of  documentation  -  9 
comment  lines  per  Ada  statement. 
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Figiure  2.  CAMP  Parts  Sizing  Data 


Figures  3  and  4  provide  the  development 
productivity  and  statistics  respectively.  As  the 
figure  illustrates,  the  productivity  experienced 
during  the  CAMP  parts  development  was  61% 
greater  than  the  predicted  value  from  the 
COCOMO  model.  Factors  leading  to  this  increase 
included  the  use  of  the  Ada  language,  well-trained 
people,  good  tools  and  code  reuse.  Specifically, 
Ada’s  attributes  (e.g.,  strong  data  typing)  contribute 
to  increased  productivity  by  allowing  early 
detection  of  errors.  The  CAMP  team  had  some  Ada 
experience  prior  to  the  program  and  received 
training  in  software  engineering  practices. 
Utilizing  software  engineering  tools  also  increased 
productivity.  Finally,  productivity  was  increased  by 
reusing  CAMP  parts  during  the  development  of 
other  parts. 


KSISN.TESTWQ 

EFFORT 


AU  EFFORT 


PARTOOOEOM.Y  PART  A  TEST  CODE 


IOOM4 

3*9 

lOC/MM 

(099 

STUTMM 

2*3  1 

STUT/MM  1 

671 

um.oc 

0407  1 

MKOC  1 

01S0 

MiSTur 

PU3 

WPSTUT  1 

0.233 

lO&WM 

2U 

lOGMM 

750 

STUT/MM 

(64 

$TUT/UU 

452 

um.oc 

OJOO 

umoc 

0223  I 

fttVSTMT 

1  09S4 

wvsTur 

OM 

Figures.  CAMP  Parts  Productivity  Data 


Hie  Parts  Engineering  System  (PES) 

With  feasibility  established  and  the 
requirements  and  design  completed  during  CAMP- 
1,  a  prototype  PES  was  coded,  tested  and 
documented  during  CAMP-2.  The  PES  consisted  of 
three  integrated  subsystems  designed  to  provide 
expert  assistance  to  the  user;  a  parts  catalog,  a 
parts  exploration  system  and  component 
constructors. 
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is  selected  for  further  user  examination  and 
subsequent  part  exploration.  Figure  6  illustrates 
the  architectural  approach. 
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Figure  4.  CAMP  Parts  Development  Statistics 


Catalog  Subsystem 

An  extensive  cataloging  capability  should  be 
the  backbone  of  any  parts  engineering  system.  The 
CAMP  PES  is  no  exception;  the  catalog  subsystem 
is  the  foundation  of  the  PES.  The  goal  of  the  parts 
catalog  is  to  help  the  PES  user  to  clearly 
understand  the  Ada  parts  and  facilitate  their 
efficient  retrieval  and  reuse.  The  catalog  allows  the 
user  to  add,  modify  or  delete  reusable  software 
entries.  It  also  provides  the  following  functions; 
searching  for  catalog  entries  based  on  various 
attribute  values,  examining  both  catalog  entries 
and  Ada  part  source  code,  and  generating  printed 
versions  of  the  catalog  entries. 


The  exploration  function  provides  the  user, 
typically  a  missile  system  engineer  or  a  missile 
software  requirements  engineer,  with  the  ability  to 
identify  potentially  applicable  parts  for  a  software 
system.  The  primary  difference  between  the 
cataloging  function  and  the  exploration  function  is 
the  latter  deals  with  a  higher  level  of  abstraction. 
The  exploration  function  allows  the  user  to  specify 
requirements  while  not  concerning  himself  with 
part  specifics.  This  function  actually  maps  the 
missile  system  requirements  to  the  parts. 
Therefore,  it  is  designed  for  use  early  in  the 
development  cycle  (i.e.,  requirementsfdcsign  phase) 
to  drive  the  design  towards  maximum  software 
reuse.  Used  early  in  the  development,  the  function 
assists  software  cost  estimate,  sizing  and  timing 
studies,  and  makc-or-buy  trade-off  studies. 

The  PES  uses  two  techniques  for  parts 
exploration.  The  first  is  the  application  approach 
and  is  designed  to  map  high-level  system 
requirements  to  existing  parts.  Through  a  series  of 
questions,  the  application  approach  generates  a  list 
of  potentially  applicable  parts.  Figure  5  depicts  the 
various  types  of  information  requested,  as  well  as 
the  selected  parts. 

The  second  exploration  technique  is  the 
architectural  approach  which  allows  the  user  to 
walk  through  a  hierarchical  model  of  missile  flight 
software.  The  models  were  developed  using 
knowledge  of  the  various  missile  systems  and  depict 
the  subsystems,  functions,  and  applicable  CAMP 
parts.  Based  on  user  inputs,  the  appropriate  model 


Figure  5.  Application  Exploration  Example 


Figure  6.  Missile  Model  Walkthrough 
(Architectural  Approach) 


The  objective  of  the  component  constructor  is 
to  generate  application-specific,  tailored  Ada  code 
based  on  user  requirements.  This  allows  the  user  to 
perform  "what  if  exercises,  as  well  as  software 
development,  while  decreasing  development  time 
and  effort. 

The  component  constructors  are  based  on 
special  parts  called  meta-parts.  These  parts  are  the 
blueprint  for  the  generated  Ada  code.  They 
facilitate  requirements  input  and  contain  all 
necessary  construction  information  for  the 
development  of  the  Ada  code. 

Twelve  component  constructors  were 
developed  in  CAMP-2  -  Kalman  Filter,  Finite  State 
Machine,  Pitch  Autopilot,  Lateral/Directional 
Autopilot,  Navigation  Subsystem,  Navigation 
Component,  Data  Bus  Interface,  Data  Type,  Task 
Shell,  Time-Driven  Sequencer,  Event-Driven 
Sequencer  and  Process  Controller. 

PES  Environment 

In  CAMP-2  the  prototype  PES  was  developed 
on  a  Symbolics  3620  computer  (the  PES  was  later 
moved  to  a  VAX  in  CAMP-3).  This  machine  is  a 
single-user  LISP  workstation  designed  to  support 
the  LISP  programming  language.  An  expert  system 
shell  was  used  as  the  foundation  for  the  PES.  The 
system  was  developed  using  ART  (Automated 
Reasoning  Tool  from  Inference,  Corp.)  and  Common 
LISP.  This  environment  was  selected  for  several 
reasons,  paramount  of  which  was  the  availability  of 
a  production  quality  expert  system  shell.  At  the 
time,  ART  was  the  most  mature  system  available 
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on  the  mevket.  This  consequently  mandated  the 
selection  of  the  processor;  ART  was  only  available 
on  the  LISP  processor. 

11th  Missile  Demonstration 

One  of  the  goals  in  CAMP-2  was  to  use  the 
CAMP  software  in  its  intended  domain  in  the  most 
realistic  situation  possible.  The  true  test  of  the 
CAMP  parts  and  the  PES  came  when  they  were 
used  to  build  the  11th  missile. 

A  cruise  missile  system  originally 
implemented  in  JOVIAL  J73  was  selected  as  the 
11th  Missile.  This  application  utilized  MIL-STD- 
1760A  (hereafter  referred  to  as  17S0A)  processors 
and  a  MIL-STD-1553B  data  bus.  Navigation, 
guidance  and  support  functions  of  the  11th  Missile 
were  re-implemented  using  the  parts  and  the  PES 
to  gauge  the  productivity  improvement  associated 
wi^  both. 

To  measure  exclusive  productivity  increases 
associated  with  the  CAMP  parts  and  the  PES,  two 
versions  of  the  11th  Missile  were  written.  Version 
one  was  written  using  parts  without  the  assistance 
of  the  PES  and  was  referred  to  as  the  parts  method. 
Version  two,  called  the  PES  method,  used  the  PES 
and  the  parts  to  generate  and  unit  test  the  Kalman 
filter  code  for  the  system.  The  re-implementation  of 
the  11th  Missile  revealed  impressive  productivity 
results. 


The  results  of  the  parts  method  evaluation 
were  very  promising.  A  productivity  increase  of 
16%  was  observed  implementing  the  llth  Missile 
using  only  the  parts  (without  the  assistance  of  the 
PES).  In  other  words,  a  development  team  would 
save  16%  of  their  efforts  if  they  were  to  implement 
the  llth  Missile  using  the  CAMP  parts  instead  of 
developing  from  scratch.  The  parts  accounted  for 
18.1%  of  the  total  llth  Missile. 

The  PES  method  resulted  in  an  convincing 
28%  improvement  in  productivity  using  the  PES 
Kalman  filter  constructor.  The  constructor 
generated  code  or  instantiated  parts  to  develop 
70.1%  of  the  Kalman  filter  component. 

Another  benefit  of  the  llth  Missile 
application  is  the  demonstration  of  Ada  used  in  a 
RTE  application.  At  the  time  of  the  evaluation,  Ada 
was  criticized  for  not  being  suitable  for  this  domain. 
The  llth  Missile  was  41. 'eloped  using 
approximately  21,000  lin-'s  0  code  and  only  21 
lines  of  assembly  code.  •  ..1  w  k-.  d  admirably  and 
is  well  suited  for  RTE  apj 

AEMONICS  ^chmarka 

A  benchmark  suite  was  also  developed  during 
CAMP-2  to  measure  the  efficiency  of  compilers  for 
suitability  for  programming  armonics  (armament 
electronics)  software.  The  benchmarks  also 
facilitated  the  evaluation  of  the  CAMP  parts.  The 
suite  contains  benchmarks  designed  to  gauge 
compilation  and  run-time  performance. 


The  CAMP  compilation  benchmarks 
determine  the  ability  of  an  Ada  compiler  to  compile 
and  link  complex  Ad.i  syntax  and  semantics 
typically  found  in  the  CAMP  parts  and  armonic 
software.  The  applicability  of  these  benchmarks  is 
not  limited  to  the  parts;  the  benchmarks  could  be 
used  for  other  domains  as  well. 

The  execution  benchmarks  include 
mathematical  functions  and  typical  use  missile 
applications  such  as  guidance,  navigation,  and 
tollman  filtering  as  benchmarks.  Run-time  data 
such  as  execution  time  and  output  are  produced  by 
these  benchmarks.  Code  size  is  also  determined. 

CAMP-3:  Tieclmology  Transition 

The  third  and  final  CAMP  phase,  CAMP-3, 
began  in  July  1988  and  will  end  in  September  1991. 
The  CAMP-3  goals  are  to  refine  and  transition  the 
technology  demonstrated  in  CAMP-2.  More 
specifically,  CAMP-3  involves  parts  maintenance 
and  enhancement,  PES  re-engineering,  meta¬ 
constructor  development,  and  various  technology 
transition  efforts. 

Parts  Maintenance 

The  primary  goal  of  parts  maintenance  was 
to  correct  possible  errors  discovered  during  the  llth 
Missile  application.  Also,  since  the  CAMP  parts 
have  been  distributed  to  nearly  300  agencies  at 
their  request,  these  agencies  were  viewed  as  a 
valuable  evaluation  source.  A  questionnaire  was 
distributed  to  all  recipients  of  the  CAMP  parts 
requesting  ideas  for  corrections,  enhancements  and 
modifications.  Meetings  were  also  conducted  to 
solicit  these  inputs  from  McDonnell  Douglas  sister 
organizations.  Only  one  error  in  the  CAMP  parts 
was  reported. 

Fifty-one  new  parts  were  identified,  designed, 
coded  and  added  to  the  parts  set  as  a  result  of  this 
maintenance  effort.  In  addition,  existing  parts  were 
enhanced  to  make  the  CAMP  parts  more  robust. 
Consequently,  the  total  number  of  parts  increased 
to  over  600. 

PES  Catalog  Re-engineering 

The  PES  re-engineering  goal  was  to  develop  a 
robust,  all-Ada,  production-quality  version  of  the 
PES.  (While  the  raeta-constructor  is  included  in  tlie 
PES,  it  is  still  regarded  as  not  production  quality.) 
As  previously  mentioned,  the  prototype  PES  was 
implemented  on  a  Symbolics  LISP  machine  using 
the  ART  expert  system  shell.  While  this  is  an 
excellent  environment  for  rapid  development  and 
prototyping  of  a  PES,  it  is  not  suitable  for  wide- 
scale  distribution  of  a  production-quality  PES.  The 
Symbolics  environment  is  very  specialized  relying 
on  system  dependencies  for  successful  PES 
operation  which  is  a  detriment  to  software  reuse. 
To  maximize  software  reuse,  the  delivery 
environment  must  be  accessible  to  several 
organizations.  This  eliminated  a  Symbolics  delivery 
system;  few  potential  CAMP  users  had  access  to 
this  machine.  Therefore,  an  Ada/microvax  platform 
was  selected.  All  PES  software  is  being  re¬ 
engineered  to  Ada  thus  exploiting  Ada’s  portability 
for  maximum  distribution.  (Of  course  the  parts 
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were  already  written  in  Ada.)  System  dependencies 
were  isolated  and  site  tailorable  features  were 
added.  All  third-party  software  was  removed  to 
eliminate  the  need  for  software  licenses. 

Meta-constructor 

The  component  constructors  developed 
during  CAMP-2  proved  the  feasibility  of  such  Ada- 
producing  capabilities.  However,  these  constructors 
are  very  costly  to  develop  and  maintain.  Therefore, 
a  meta-constructor  is  being  developed  during 
CAMP-3  to  alleviate  these  problems.  A  meta¬ 
constructor  is  a  constructor  designed  to  produce 
other  component  constructors.  This  approach  will 
lower  the  overall  cost  of  developing  constructors 
and,  ultimately,  tailored  Ada  code. 

llBchnology  Transition 

Perhaps  the  most  important  responsibility  of 
a  program  manager  is  technology  transition.  A 
successful  program  will  benefit  no  one  if  it  is  not 
made  available  to  the  intended  user.  CAMP’s 
ultimate  users  are  software  engineers  and  weapon 
systems  developers.  Therefore,  the  CAMP-3 
program  embarked  on  an  aggressive  technology 
transition  campaign  which  included  the 
development  and  distribution  of  a  CAMP  brochure, 
a  reuse  manual  and  a  videotape,  as  well  as  a 
demonstration  of  CAMP  in  action  at  a  national 
conference  -  Tri-Ada  ’90.  The  moat  significant 
technology  transition  effort  was  the  actual 
distribution  of  the  CAMP  parts  and  catalog  as 
previously  discussed. 

A  brochure  was  also  developed  to  "spread  the 
word"  about  CAMP.  It  explains  the  entire  CAMP 
effort  and  contains  a  complete  listing  of  all  products 
including  the  actual  parts  and  documentation.  A 
partial  list  is  provided  at  the  end  of  this  paper.  The 
brochure’s  greatest  asset  is  information  on  how  to 
obtain  these  products.  This  brochure  is  available 
from  either  the  McDonnell  Douglas  CAMP  program 
manager,  (314)  232-0278,  or  the  USAF  CAMP 
program  manager,  (904)  882-8264. 

One  of  the  most  popular  commodities  is  a 
manual  entitled  "Developing  and  Using  Ada  Parts 
in  Real-Time  Embedded  Applications."  The  manual 
embodies  the  overall  CAMP  experience  and  includes 
informative  te  Uniques  and  methods  for  developing 
and  using  Ada  parts  in  the  real-time  embedded 
realm.  The  manual  is  available  from  the  Defense 
Technical  Information  Center  (DTIC)  by  ordering 
document  number  AFATL-TR-90-67. 

An  executive  overview  videotape  was  also 
produced  to  describe  Ada  issues,  software  reuse 
issues  and  how  the  CAMP  program  attempts  to 
alleviate  them.  The  videotape  has  been  distributed 
to  nearly  70  organizations  to  heighten  awareness  of 
the  CAMP  approach  to  the  software  crisis. 

Conclusions 

CAMP  has  been  a  pathfinding  program  in 
several  respects.  It  demonstrated  that  software 
reuse  is  feasible  and  valuable  and  that  Ada  can 
effectively  handle  real-time  embedded  applications. 
Throughout  the  CAMP  program,  one  theme 


emerged:  Software  reuse  and  the  development  of 
software  parts  must  be  precisely  planned.  An  ad 
hoc  approach  to  software  reuse  is  destined  to 
failure. 

“The  future  of  software  reuse  is  bright.  CAMP 
took  a  tremendous  step  towards  institutionalizing 
software  reuse  as  a  standard  way  of  doing  business. 
Indeed,  industry  must  rely  more  and  more  on 
software  reuse  to  remain  competitive  in  this  era  of 
austere  budgets. 
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Other  Readings/Materials 

The  following  CAMP  documents  are  available 
through  the  Defense  ’Technical  Information  Center: 

Developing  and  Using  Ada  Parts  in  Real- 
Time  Embedded  Applications:  A  manual  that  gives 
guidance  in  how  to  develop  and  use  reusable 
software.  Order  AFATL-TR-90-67. 

CAMP-1  Final  Technical  Report:  Three 
volumes  covering  domain  analysis,  parts 
specification,  parts  composition  system  study. 
Order  AFATL-TR-86-93,  Volumes  1-3. 

CAMP-2  Final  Technical  Report:  Three 
volumes  covering  parts  and  parts  composition 
system  development,  llth  Missile  Application 
development,  and  Armonics  Benchmarks 
development.  Chder  AFATL-TR-88-62,  Volumes  1-3. 

The  CAMP  software  products  listed  below  are 
available  through  the  Data  &  Analysis  Center  for 
Software,  P.O.  Box  120,  Utica,  New  York  13503;  the 
telephone  number  is  (315)  336-0937. 

CAMP  Ada  Parts:  ANSI  standard  tapes 
containing  source  code  for  the  parts,  test  code  and 
utilities,  and  design  documents  in  machine  readable 
form. 


Parts  Engineering  System  (PES)  Catalog 
Version  1.1:  ANSI  standard  tapes  containing  the 
CAMP  catalog  and  the  data  needed  to  load  it  with 
the  CAMP  parts.  This  is  in  Ada,  uses  no 
commercial  third-party  software,  and  runs  under 
VAXA^MS. 

Benchmark  Tape:  An  ANSI  standard  tape 
containing  the  benchmarks,  standard  data  files, 
and  VAX  command  procedures  for  executing  the 
benchmarks  on  VAX  hardware. 
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1 ■  Summary 

In  Flight  Safety  Critical  Systems  where  the 
lives  of  people  and/or  mission  success  is 
depending  on,  errors  in  the  Computer 
Software  Components  can  have  a  catastrophic 
impact  on  the  safety. 

The  requirements  for  the  software 
development  and  maintenance  of  Flight 
Safety  Critical  systems  differ  in  some 
aspects  from  the  systems  which  do  not  fall 
into  this  category.  The  reason  for  these 
requirement  is  to  produce  "the  right 
product"  at  the  very  beginning  of  the 
system's  usage  and  to  ensure  special 
attention  is  paid  throughout  the  whole 
service  life  of  the  equipment. 

The  reliability  and  safety  requirements  can 
reach  a  point  where  testing  alone  is  not 
sufficient.  Consequently  adequate  control 
mechanisms  have  to  be  applied.  The  software 
configuration  management,  quality  control, 
verification  and  validation  must  be 
rigorously  adhered  to. 

For  the  development  of  the  equipment 
software,  a  set  of  development  standards 
and  additional  procedures  for  the 
implementation  of  Safety  Critical  Functions 
are  defined. 

LITEF  applied  the  standards  and  procedures 
for  the  development  of  the  Inertial 
Measurement  Unit  which  is  a  part  of  the 
Flight  Control  System  and  Seat  Sequencer 
Unit  which  is  part  of  the  Ejection  Seat. 

In  this  paper,  some  critical  technology 
needs  are  described  for  supporting  the 
development  and  verification  process  of 
such  systems  and  the  activities  which  have 
to  be  performed  during  the  development 
phases  for  identifying,  assessing  and 
eliminating  or  minimizing  hazards  in  a 
systematic  way. 


2.  Introduction 

In  recent  years,  software  has  gradually 
been  given  more  and  more  responsibility. 
Today  the  software  has  complete  control 
over  many  Safety  Critical  Functions  on  some 
air  vehicles.  In  fact,  it  would  be 
impossj.ble  for  a  human  to  manually  fly 
several  of  the  modern  aircrafts.  This  is 
because  they  require  complex  control  Inputs 
at  faster  than  human  speeds  in  order  to 
prevent  loss  of  control  leading  to  a  crash. 
However  the  question  persists.  Are  we  able 
to  verify  that  the  software  is  sufficiently 
free  from  errors  which  would  have  a 
catastrophic  impact  on  the  safety?. 


It  would  be  fair  to  ask  the  questions: 
"what  are  the  risks  incurred  by  using  the 
software?"  and  "what  is  the  probability 
that  the  plane  will  crash  due  to  a  fault  in 
the  software?".  From  the  point  of  view  of 
the  pilot,  who  doesn't  care  if  the  problem 
is  the  hardware  or  the  software,  the  issue 
may  be  rephrased  and  put  into  the  bigger 
context.  "Given  that  I  am  going  to  fly  that 
airplane  on  a  one-hour  mission  today,  what 
are  my  chances  of  returning  safely?". 


3.  Knowledge  Base 

Originally  each  software  system  will  be 
considered  as  "unsafe".  This  label  can  be 
only  removed  and  replaced  by  a  "safe"  label 
after  sufficient  knowledge  about  its  safety 
status  exists. 

A  newly  designed  software  for  which  there 
is  none  or  little  knowledge  in  the  way  of 
analysis  and  test  results  can  not  be 
considered  safe. 

On  the  other  hand,  it  could  happen  that  the 
entire  analysis  and  testing  of  software 
reveals  no  need  for  changes.  At  the  end  of 
the  qualification  of  the  software  which  was 
originally  labelled  "unsafe",  it  is 
determined  to  be  "safe",  even  though 
absolutely  no  changes  were  made.  The  only 
thing  that  has  changed  since  the  initial 
design  release  was  our  knowledge  about  the 
entity  in  question. 

As  the  figure  above  illustrates,  the 
quality  of  the  established  standards  and 
procedures,  methods  and  tools,  prepared 
documentation,  review  reports,  the  results 
of  the  verification,  testing  and  software 
safety  analysis  will  Impact  the  decision 
making  process  related  to  the  safety  of  the 
software. 

Not  to  forget  the  engineers  who  participate 
in  the  development  of  the  project. 


4.  Development  Standards 

A  structured  development  philosophy  and 
Verification  and  Validation  approach  is 
particularly  important  in  the  case  of 
Flight  Safety  Critical  Systems.  Much 
documentation  exists  relative  to  standards, 
procedures,  methods,  tools  and  environment 
which  support  this  type  of  development. 
Standards  and  guidelines  are  described  in 
a  sophisticated  way  and  must  be  applied  to 
the  related  projects.  The  efforts  required 
during  the  development  process  increases 
with  the  criticality  of  the  application. 
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Figure  1  Knowledge  Base 


For  each  of  the  five  major  category  of 
activities  which  are  : 

-  Software  project  management 

-  Software  configuration  management 

-  Software  quality  evaluation 

-  Software  engineering 

-  Software  testing 

detailed  tasks  are  defined.  Model  texts 
will  help  the  engineers  to  prepare  the 
documentation  in  a  standard  way. 

In  order  to  minimize  the  vary  costly  and 
most  difficult  to  detect  errors  in  the 
early  phases  of  the  Software  projects,. 
Methods  and  tools  Application  Standards, 
Design  and  Coding  Standards  are  specified 
to  support  effectively  the  production  of 
the  software.  In  the  requirements  analysis 
phase,  the  design  phases,  and  the  coding 
phase. 

In  addition  development  guidelines  and 
procedures  for  software  safety  tasks  are 
established. 


5.  Safety  Analysis  Activities 

The  objectives  of  the  safety  analysis  tasks 
are  : 

-to  identify  the  hazards 
-to  eliminate  the  hazards  if  possible 
through  design  or  reducing  the 
associated  risks  to  an  acceptable  level 
-to  minimize  the  hazardous  events 

The  analysis  will  result  in  reports, 
recommendations,  guidelines  and  corrective 
actions. 

The  fundamental  principles  to  achieve  a 
high  degree  of  flight  safety  are: 

-System  bevel  Management 
-Flight  Safety  Analysis 
-Information  Flow 

The  Plight  Safety  Program  is  a  top  level 
system  engineering  activity  which 
integrates  flight  safety  concept  and 
analysis  into  all  phases  of  the  project. 
The  Software  Safety  Analysis  is  performed 
in  parallel  to  other  development  activities 
and  is  accomplished  from  the  system  level 
d.,«n  to  til.''  component  level.  It  is  a  step 


by-step  procedure  which  attempts  to 
exhaustively  identify  all  potential  hazards 
to  which  the  system  or  its  functions,  could 
be  subjected  to.  It  is  fundamentaly  a  top- 
down  approach  which  goes  as  deep  as 
necessary  in  order  to  adequately  describe 
the  hazards  with  respect  to  their 
consequences  on  flight  safety.  The  hazard 
analysis  is  structured  into  a  hierachy. 

In  order  to  manage  and  coordinate  the 
flight  safety  related  activities,  a  flight 
safety  engineer  with  enough  experience  and 
thorough  knowledge  about  the  application, 
hardware,  software,  shall  be  appointed  to 
the  project. 

In  order  to  perform  a  comprehensive 
analysis,  the  flight  safety  engineer  must 
collect  and  organize  all  information 
related  to  the  software  development 
process.  The  relevant  data  to  the  flight 
safety  is  focussed  and  used  in  the  flight 
safety  analysis  process. 

Based  on  the  preliminary  list  of  potential 
hazards  and  given  the  system's  operational 
environment,  the  system  safety  engineer 
develops  hazard  scenarios.  A  scenario  is 
the  possible  sequences  of  events  and 
circumstances  that  can  lead  to  a 
consequence.  For  each  event  involved  in  the 
hazard  scenario,  the  system  safety  engineer 
considers  failure  modes  that  can  lead  to 
these  events. 

Different  techniques  are  known  for  the 
accomplishment  of  the  hazard  analysis. 
LITEF's  approach  for  identification  of  the 
hazards  in  the  Software  requirements 
analysis  phase  and  the  preliminary  design 
phase  is  the  usage  of  the  'Fault  Tree' 
technique  .  Based  on  critical  signals 
defined  in  the  specification,  the  critical 
functions  in  the  Software  Requirements 
Specification  and  associated  Computer 
Software  Components  (CSC)  in  the  'Software 
Top  bevel  Design  Document'  are  identified. 

Critical  functions  and  interfaces  are 
identified  and  allocated  to  the  system 
components.  Multiple  systems  with 
dissimilar  software,  Backup  systems, 
redundant  configurations  shall  be 
considered  in  the  overall  design  so  that 
flight  safety  failures  can  only  occur  as  a 
result  of  multiple  failures. 
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Figure  2  Planning  model 


The  analysis  continues  in  the  software 
detailed  design,,  coding  and  unit  testing 
phase. 

The  objectives  of  the  tasks  during  the 
detailed  design  phase  are  : 

-to  Identify  potential  failures  and 
define  their  affects  on  safety 
-to  identify  necessary  design  changes 
-to  identify  the  extensiveness  required 
for  testing  and  V&V  activities 


In  order  to  complement  the  system  safety 
tasks  and  reaching  the  objectives  defined 
for  software  safety,  a  Failure  Mode,. 
Effects  and  Criticality  Analysis  (FMECA)  is 
performed  in  the  detailed  design  phase.  The 
level  of  analysis  in  this  phase  is  the 
computer  software  unit  (CSU)  level.  These 
units  are  identified  in  the  detailed  design 
document.  A  CSV  is  examined  to  determine 
its  impact  on  the  reliability  and  safety. 
Functions  and  units  which  are  identified  as 
critical  during  FMECA  will  undergo  a  more 
extensive  testing. 

Following  steps  are  performed  for  FMECA  : 

-Planning 

-Analysis 

-Reporting 

The  details  of  the  analysis  approach, 
documentation  and  worksheets,.  report 
formats,  interfaces  and  other  analyses 
performed  at  the  code  level  are  defined  in 
the  FMECA  plan. 

Failure  severity  category  and  hazard 
consequence  severity  category  are  assigned 
to  each  computer  software  unit. 

Static  and  Dynamic  code  analysis  are 
performed  to  the  source  code.  The  objectve 
of  Static  code  analysis  is  to  identify  the 
deficiencies  in  the  data  flow,  control  flow 
and  information  flow  and  to  assess  the 
complexity  of  the  programs. 

The  objective  of  dynamic  code  analysis  is 
to  verify  that  the  test  cases  for  the  units 
provide  sufficient  coverage  of  the  source 
code. 

These  acivities  are  performed  in  accordance 
with  the  Mil-STD-882B  task  series  300. 


6.  Safety  testing 

Testing  is  generally  performed  until  the 
test  engineers  feel  confident  that  the 
software  is  reliable  enough  and  can  be 
released.  Various  testing  and  reliability 
models  has  been  developed  to  determine  the 
level  of  reliability,  normally  these  models 
does  not  address  the  failure  impact  in  the 
case  of  safety  critical  systems.  The  amount 
of  testing  required  is  heavily  dependent  on 
the  potential  effects  of  failure  on  the 
flight  safety. 

In  order  to  define  the  specific  safety 
testing  requirements  in  the  functional, 
component  and  unit  level  of  the  software, 
LITBF  uses  the  results  of  the  flight  safety 
analysis,  statistical  data  of  the  previous 
projects  and  the  on-going  test  results. 

Unit  risk  is  estimated  based  on  the  data 
described.  The  tests  are  planned 
proportionally  to  the  risk  of  each  unit. 

Units  are  classified  by  relating  the  units 
to  the  hazards  and  their  consequences.  In 
the  detailed  design  phase  all  units  are 
analyzed  to  identify  those  which  use  or 
update  the  data  related  to  the  critical 
functions.  The  units  are  classified 
according  to  their  impacts  on  the  safety. 

In  addition  the  expected  number  of  faults 
per  unit  is  estimated.  This  estimation  is 
based  on  the  complexity  of  the  unit  and  the 
statistical  data  which  are  collected  during 
past  years  for  units  of  similar  projects. 
The  a  priori  distribution  for  the  unit 
reliability  is  formulated  for  each  unit 
after  it  has  been  coded. 

The  unit  classification  and  unit 
reliability  model  both  will  serve  as  a 
qualitative  assessment  of  the  unit  risk  and 
consequently  a  better  planning  of  test 
efforts . 

During  the  unit  test  phase  and  subsequent 
phases,  the  unit  fault  statistics  are 
collected.  The  unit  fault  rates  used  for 
the  updates  of  the  a  priori  distribution 
and  consequently  the  test  plan. 


7.  Application 

The  Seat  sequencer  software  is  categorized 
as  flight  safety  critical. 

It  is  a  microprocessor  based  unit  which 
controls  the  timing  of  the  various  seat 
sub-systems  (e.g.  drogue  canister  catapult 
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firing,  parachute  container  catapult 
firing) .  Control  of  these  timings  will  be 
based  on  information  provided  by  seat 
sequencer  mounted  sensors  which  establish 
the  ejection  conditions  of  acceleration, 
base  pressure  and  dynamic  pressure.  The 
sequencer  operates  independently  of  the 
aircraft. 

The  system  architecture  constitutes  the 
following  principles  : 

-triple  redundant  microprocessor 
channels 

-redundant  sensing  of  environmental 
conditions 

-harmonization  of  Intermediate  results 
between  channels 

-2-of-3  H/W  voting  before  Electro 
Explosive  Devices (EED) -Ignition 

The  basic  design  philosophy  is  to 
completely  eliminate  single  point  failures 
by  building  a  triple  redundant  system. 

Each  seat  sequencer  channel  contains  the 
same  program.  Each  channel  samples  the 
environmental  data  during  the  ejection.  The 
intermediate  results  of  each  microprocessor 
channel  is  harmonized  with  both 
neighbouring  channels.  The  EED  ignition 
decision  of  each  channel  is  passed  to  a 
hardware  voter  which  in  turn  ma)ces  a  2-of-3 
voting  for  a  final  ignition  decision. 

The  organization  of  the  software  is  very 
simple  given  the  critical  nature  of  the 
application.  It  implies  the  repetitive 
execution  of  tas)cs  within  a  predefined 
period  of  time. 

In  order  to  facilitate  the  target  testing 
of  the  units  and  the  Computer  Software 
Components  (CSC's),  consideration  has  been 
made  in  the  overall  software  design.  Each 
CSU  or  CSC  can  be  isolated  from  the  other 
parts  of  the  software  by  external  commands 
and  tested  by  downloading  the  individual 
data  of  different  test  cases. 

The  sequencer  is  considered  to  oe  flight 
safety  critical  for,  if  the  sequencer  fails 
to  fire  the  pyrotechnics  in  the  correct 
sequence  and  at  the  correct  time. 

Based  on  this  top  level  hazard,  the  system 
is  analyzed  and  the  sub  events  which  can 
lead  to  the  top  event  are  identified.  This 
analysis  are  continued  until  the  basic 
events  are  reached.  The  fault  tree 
technique  has  been  used  for  this  analysis. 
Based  on  the  safety  analysis,  a  report  is 
prepared  and  recommendations  have  been 
given  for  the  re-design  or  as  requirements 
for  the  subsequent  activities. 
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7.  Concl u Sion 


A  software  development  methodology  has  been 
presented  to  produce  highly  reliable 
software  for  flight  safety  critical 
applications . 

In  addition  a  test  planning  method  for  this 
type  of  applications  has  been  presented. 
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